[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