[Nix-dev] [***SPAM***] Dynamic Dependency Management by Calling External Programs from Nix

Eelco Dolstra e.dolstra at tudelft.nl
Wed Oct 26 17:38:28 CEST 2011


On 10/26/2011 05:30 PM, Shea Levy wrote:

>> However, you don't want this most of the time, certainly not in Nixpkgs, because
>> it causes query operations like "nix-env -qa" to do a build.  Which is a bad
>> thing.  Actually, since "nix-env -qa" runs in read-only mode, it won't even work
>> (but it will work for "nix-env -i", "nix-instantiate" or "nix-build").
> 
> Presumably, most of the packages that want this ability will end up being
> functions (e.g. a function that takes a Haskell package name and evaluates to
> derivation that builds that package with its dependencies as separate
> derivations). What will nix-env -qa do when faced with something like
> pkgs.haskellPackage as a function?

It barfs ungracefully:

$ nix-env -f . -qa \* --drv-path
error: cannot import `/nix/store/1ll18rx1gvcvacdhwbrwzg5xg760i933-x', since path
`/nix/store/23jzna04rkcrpfflhg9w09d6y5g4h60f-x.drv' is not valid
(use `--show-trace' to show detailed location information)

(So if the output of the derivation already exists, it will actually work.)

> Maybe it would be desirable to make it so tools that evaluate/instantiate only
> (nix-env -qa, nix-instantiate, --dry-run, etc.) gracefully ignore
> store-dependent imports unless given a specific flag to build them (or unless
> the required output has already been built)?

But that would mean that if we use this to compute packages on the fly (e.g. to
solve dependencies dynamically), then "nix-env -qa" won't show those packages.

> So we're already doing this in nixpkgs? How do nix-env -qa and the like respond?

No, these functions are not actually used by any package in Nixpkgs.  But
they're used (e.g.) by Hydra jobs.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/


More information about the nix-dev mailing list