[Nix-dev] wrapProgram: also pass name as NIX_PROGRAM_NAME

[Graham Christensen]

I think it is worth investigating using C or something for wrappers, as
wrappers on macOS can't be used in shebangs. Wrapped ruby executables have
to be unwrapped to use.

Would using C solve your problems as well?
On Mon, May 22, 2017 at 11:00 AM Freddy Rietdijk <freddyrietdijk at fridh.nl>
wrote:

> The problem with such an environment variable is that it's inherited by
>> child
>> processes, who might get confused. (E.g. some code might run both in a
>> wrapped
>> and unwrapped context, so it wouldn't be able to rely on $NIX_PROGRAM_NAME
>> unambiguously.)
>
>
> In the case of Python we might be able to inject some code where we unset
> the variable. Currently we inject the path to the script, but this is wrong
> in case a wrapper is used.
>
> I think in general a) wrappers should be avoided; and b) nested wrappers
>> should
>> *definitely* be avoided. Wrappers cannot really be avoided for the
>> "delayed
>> composition" use case (like firefox-wrapper), but in such a case perhaps
>> the
>> inner wrapper can be eliminated. For example, if the inner wrapper is
>> used to
>> set $PYTHONPATH, this can be moved into the underlying Python script by
>> setting
>> sys.path at the start.
>
>
> When possible I would prefer to avoid wrappers as well. Unfortunately,
> there's not really a way around it with Python (2.x).
> Sometimes we need to add a program to PATH and for that we need a wrapper.
> When we add the wrapper, the name is wrong. if the wrapper is added in the
> same derivation, then we can insert sys.path like we do now.
>
> However, often we also need composition: creating an environment
> consisting of the interpreter and multiple packages. In that case, they
> need to be able to find each other, and that means again wrappers (although
> with 3.x we might get away with pyvenv.cfg).
>
> On Mon, May 22, 2017 at 2:36 PM, Eelco Dolstra <
> eelco.dolstra at logicblox.com> wrote:
>
>> Hi,
>>
>> On 05/19/2017 01:35 PM, Freddy Rietdijk wrote:
>>
>> > Therefore, I propose we set an environment variable `NIX_PROGRAM_NAME`
>> that the
>> > scripts check for. To prevent creating yet another `wrapProgram`
>> variant I
>> > propose we extend `wrapProgram` to always set this variable.
>>
>> The problem with such an environment variable is that it's inherited by
>> child
>> processes, who might get confused. (E.g. some code might run both in a
>> wrapped
>> and unwrapped context, so it wouldn't be able to rely on $NIX_PROGRAM_NAME
>> unambiguously.)
>>
>> But maybe $NIX_PROGRAM_NAME can be used only in the case where one wrapper
>> script calls another, so the final wrapper can unset it. However, if we
>> have
>> wrapper scripts detecting that the wrapped program is also a wrapper
>> script, we
>> might as well eliminate the execve into the next wrapper (thus preserving
>> the
>> original argv[0]).
>>
>> > This, however, doesn't solve the issue with nested wrappers yet
>>
>> I think in general a) wrappers should be avoided; and b) nested wrappers
>> should
>> *definitely* be avoided. Wrappers cannot really be avoided for the
>> "delayed
>> composition" use case (like firefox-wrapper), but in such a case perhaps
>> the
>> inner wrapper can be eliminated. For example, if the inner wrapper is
>> used to
>> set $PYTHONPATH, this can be moved into the underlying Python script by
>> setting
>> sys.path at the start.
>>
>> --
>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170522/a309e59c/attachment-0001.html>