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.fors...@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@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
