d17f0f9cbc
`callPackage' was described here:
http://www.mail-archive.com/nix-dev@cs.uu.nl/msg02624.html
It allows all-packages.nix to be shortened significantly (from 10152
to 6980 lines) by automatically filling in package functions'
required arguments from `pkgs'. That is, a function
{ stdenv, fetchurl, libfoo, libbar }: ...
can now be called as
callPackage ./<bla>.nix { };
rather than
import ./<bla>.nix {
inherit stdenv fetchurl libfoo libbar;
};
This reduces boring typing work when adding a dependency and reduces
the number of trivial commits to all-packages.nix.
Overrides or arguments that don't exist in `pkgs' can be passed
explicitly, e.g.,
callPackage ./<bla>.nix {
libfoo = libfoo_1_2_3;
};
The conversion was done automatically with a magic Perl regexp. I
checked that `nix-env' produces the same results before and after
(except for three packages that depend on webkit, which uses
deepOverride).
`callPackage' applies `makeOverridable' automatically, so almost
every package now exports an `override' function.
There are two downsides to using callPackage:
- Evaluation is a bit slower (about 15% on `nix-env -qa --drv-path
\*').
- There can be unexpected results for functions that have default
argument values. For instance, a function
{ libfoo ? null }: ...
called using `callPackage' will be passed a `libfoo' argument
provided that `pkgs.libfoo' exists. If this is used to control
whether a package has to have a certain dependency, you need to
explicitly write:
callPackage ./<bla>.nix {
libfoo = null;
};
svn path=/nixpkgs/trunk/; revision=22885
|
||
|---|---|---|
| .. | ||
| applications | ||
| build-support | ||
| data | ||
| desktops | ||
| development | ||
| games | ||
| lib | ||
| misc | ||
| os-specific | ||
| servers | ||
| shells | ||
| stdenv | ||
| test | ||
| tools | ||
| top-level | ||