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

[Freddy Rietdijk]

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170522/e922b86b/attachment.html>