[Nix-dev] Re: [Nix-commits] SVN commit: nix - 15706 - ludo - in nixpkgs/trunk/pkgs: development/python-modules development/python-modules/generic top-level

Ludovic Courtès ludo at gnu.org
Tue May 26 00:06:24 CEST 2009


Hi,

Eelco Dolstra <e.dolstra at tudelft.nl> writes:

> This kind of construct:
>
>> +    (if attrs ? buildInputs then attrs.buildInputs else []);
>
> can be eliminated by writing the function as:
>
> { buildInputs ? []
> , doCheck ? true
> , ... # <-- literal "..."
> } @ attrs:
>
> Actually, since you don't have a " // attrs" in the mkDerivation call, you could
> leave out the "..." and the "@ attrs".

Hmm, indeed!

(Will commit it as soon as I can...)

>> +          wrapProgram "$i"                          \
>> +            --prefix PYTHONPATH ":"                 \
>> +            ${lib.concatStringsSep ":"
>> +               ([ "$out/lib/${python.libPrefix}/site-packages" ] ++
>> +                (map (path: path + "/lib/${python.libPrefix}/site-packages")
>> +                     (lib.concatMap recursiveBuildInputs
>> +                                    propagatedBuildInputs)))}
>
> It's more efficient to do this in shell code rather than in the Nix expression.
>  In fact, $PYTHONPATH should contain all the propagated build inputs.  So I
> think  that
>
>   wrapProgram "$i" --prefix PYTHONPATH ":" $PYTHONPATH
>
> should work.

Right, but $PYTHONPATH may also contain `buildInputs' (e.g., Python
packages that are only used when running the test suite, or `setuptools'
plug-ins, etc.), which we'd rather avoid.  How can it be achieved in
shell script?

Thanks,
Ludo'.



More information about the nix-dev mailing list