[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