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

[Bjørn Forsman]

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