[Nix-dev] A generic wrapper method (possibly)

[Bjørn Forsman]

Hi Eelco,

On 2 December 2013 15:23, Eelco Dolstra <eelco.dolstra at logicblox.com> wrote:
> Hi,
>
> On 30/11/13 16:12, Bjørn Forsman wrote:
>
>> I envision the end result to be something like this:
>>
>> stdenv.mkDerivation {
>>   name = "foo-0.1";
>>   ...
>>   buildInputs = [ python pythonPackages.jedi ];
>>   runtimeInputs = [ python pythonPackages.jedi ];
>>   ...
>> }
>>
>> (The use of python above is arbitrary. You could for instance replace
>> it with bash + some deps that should be found in PATH.)
>>
>> The above derivation, when built, would construct a wrapped instance
>> of the python interpreter which knows where to find the jedi package.
>> And this interpreter would be used in the patchShebangs function.
>> Automatically.
>>
>> What do you think? Does this sound like a good idea?
>
> Using a wrapped interpreter certainly sounds nicer than using a wrapper.  I see
> two problems:
>
> - wrapProgram is used for more than adding runtime inputs; it can also set
> arbitrary environment variables (e.g. $MOZ_PLUGIN_PATH in the Firefox wrapper).

Yes, I know :/

> - You may want to have different runtime inputs for different programs in a
> derivation.

Hm, I see. I guess this is an issue only for multiple-output derivations where
using runtimeInputs would remove the possibility to drop some unneeded
runtime deps.
But in single output derivations there is nothing to gain I think.

> An alternative that I've been thinking about is to make wrapProgram smarter by
> giving it interpreter-specific backends.  For instance, if the program to be
> wrapped is a shell script, we don't need to generate a wrapper: we can just add
> some lines to be top of the shell script.  Likewise for other interpreted
> languages.

Yes, that sounds much simpler. And it preserves the possiblity to add
arbitrary env-vars
like we have today.

And this is probably the fastest solution to implement and for the CPU
to execute.
Instead of doing extra exec, just interpret a few extra lines.

I like it. +1.

> It may even be possible for ELF executables (patchelf could override
> the main() function to do some setenv() calls).

Cool! I didn't think of that!

Best regards,
Bjørn Forsman