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

[Sergey Mironov]

Hi! Plus one from here. I also notice '.myapp-wrappers' while
alt-tab-switching tasks and it is not good for the endusers.

A note about binary programs. May we say that applying a wrapper
breaks only applications with interpreters (like python, shell, perl)
and does not affects binary applications? Looks like no, since binary
apps may also read their argv[0] and make decisions. What may be done
in such cases? Crazy idea - patch the libc and make it support
something like FORCE_ARGV0 variable? Sounds dangerously and fixes one
aspect but there may be others. Luckily, looks like binaries rarely
depends on their names  so we probably may ignore the problem like we
do now and fix things locally on demand.

Regards,
Sergey

2013/12/2 Alex Berg <chexxor at gmail.com>:
> I am interested in this topic. I don't completely understand the problem
> here, but maybe I can help by discussing it.
>
> The motivation for the addition of "runtimeInputs" is primarily to support
> language interpreters and their libraries?
>
> I really don't like to use "wrapper", this term. I feel that it's a term
> used when the problem isn't well understood and the solution is lazily
> designed. If we can rewrite this concept using an attribute which has a
> better name, this would definitely be a good change.
>
> First, I would like to better understand the concept. How do you want to use
> these "runtimeInputs"? You want to add them to an environment variable, such
> as "PATH", and keep this value after the build environment closes? Or you
> want to modify the interpreter's package by adding symlinks to this
> "buildInputs" packages?
>
> Currently, "buildInputs" packages are built before the package, and their
> "bin", "lib", and "include" directories are added to certain environment
> variables so other tools can find them, but only during the build. Am I
> wrong, or does it do other important things? (If there's documentation that
> fully explains the effects of adding a package to this attribute, please
> link me.)
>
> Also, I remember that "propagatedBuildInputs" also exists. I don't
> understand its exact purpose, but I believe it shares environment variables
> between dependencies, from child to parent packages. Is "runtimeInputs"
> similar?
>
>
>
>
> On Sun, Dec 1, 2013 at 5:12 AM, Bjørn Forsman <bjorn.forsman at gmail.com>
> wrote:
>>
>> Hi all,
>>
>> For a long time I've been annoyed by the side effects of wrapping
>> programs. Now I want to fix it.
>>
>> Wrapping programs makes the help text (very often) ugly: "usage:
>> .prog-wrapped some-option" instead of "usage: prog some-option".
>> Whenever I see such help texts I cannot help but think that our
>> current solution is very hacky. But the most important side effect is
>> that some programs actually break when wrapped, because their argv[0]
>> is different than it normally is; it has gotten a '.' in front and
>> '-wrapped' at the end. I've seen this breakage in dblatex (IIRC) and
>> munin (100% sure).
>>
>> What can we do about it?
>>
>> Peter Simons recently rewrote the python wrapper so that the python
>> interpreter itself finds its dependencies instead of having to going
>> through a different shell script that sets PYTHONPATH for it. (Well
>> actually, there is a shell script involved, but it's different.)
>>
>> I have this idea that we can do a similar thing for other interpreters
>> like sh, perl etc. My goal is to have "wrapped interpreters" instead
>> of the current "wrapper scripts around programs that use plain
>> interpreters". (Of course, I don't think that we can stop using
>> wrapProgram alltogether, but the common stuff I think we can make
>> better.)
>>
>> 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?
>>
>> As a start I've made a bash-wrapper (basically a copy of the python
>> wrapper.nix file) to try fixing the munin package plugins. I'm now
>> pondering how to to implement the "runtimeInputs" functionality. I
>> imagine that the stdenv builder would have to be extended with hooks
>> so that "if bash in runtimeInputs then build bash-wrapper" and "if
>> python in runtimeInputs then build python-wrapper". And patchShebangs
>> must have these wrapped interpreters first in PATH.
>>
>> But this is where it stops for me. I have no idea how to implement "if
>> bash in runtimeInputs then build bash-wrapper" and put that wrapper
>> first in PATH. Any hints appreciated.
>>
>> Also if anyone thinks this runtimeInputs thing is a bad idea, please
>> say so. And explain why :-)
>>
>> Best regards,
>> Bjørn Forsman
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>