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

Shea Levy shea at shealevy.com
Wed Oct 26 17:30:46 CEST 2011


Hi,

On 10/26/11 11:14 AM, Eelco Dolstra wrote:
> Hi,
>
> On 10/25/2011 01:35 AM, Shea Levy wrote:
>
>> So I'd really like to see one of two solutions implemented (I'll do the
>> implementation myself if Eelco is willing to consider accepting these solutions)
>> in nix (possibly with an explicit command-line flag or nix.config setting to
>> enable them, like we have with enableParallelBuilds):
> You can do what you want today, since the "import" function (as opposed to
> builtins.readFile) supports importing the output of a derivation.  I.e. you can do
>
>    let drv = runCommand ... "some command that generates $out/foo.nix" ...
>    in import "${drv}/foo.nix"

Ah, great! I didn't realize this was already an option.

>
> 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?

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)?  I understand the concern about not having this feature used in 
nixpkgs, but I think in some cases it's useful enough that I'm willing 
to set up enough stumbling blocks to let it be used when necessary 
without breaking things for people who don't want it.

> There are a few examples of this:
>
> - https://nixos.org/repos/nix/nixpkgs/trunk/pkgs/build-support/vm/default.nix;
> here we import the output of the functions rpmClosureGenerator and
> debClosureGenerator (a derivation that builds a Nix expression containing
> fetchurl calls to download the required RPMs or Debs).
>
> - https://nixos.org/repos/nix/nixpkgs/trunk/pkgs/misc/tex/nix/default.nix; the
> function to build a LaTeX document does "deps = import (pkgs.runCommand
> "latex-includes" ..." to figure out the dependencies of the document (e.g.,
> \input{...}) on the fly.

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

> - https://nixos.org/repos/nix/attic/make/lib/default.nix does a similar thing to
> figure out the header file dependencies of a C file.
>

Thanks for the info, glad I didn't do any work implementing this.

~Shea


More information about the nix-dev mailing list