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

[Bjørn Forsman]

Hi Alex,

On 2 December 2013 09:43, Alex Berg <chexxor at gmail.com> wrote:
> 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?

Yes. For C/C++ buildInputs tend to "stick" into the binaries/libraries
through RPATH.
So they have automatic/implicit runtime deps handling. But there is no
similary "stickyness"
for e.g. shell scripts and python programs. That's why we currently
use wrapProgram and
such to make the dependencies "stick around" after the build
environment is destroyed.

> 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?

The latter.

Say that the derivation for progA has runtimeInputs = [ bash dep1 dep2
]. Nix should
build a symlink tree with bash, dep1 and dep2. Then modify bash so that it gets
PATH=symlink-tree/bin (either with a wrapper or sourcing some setup
code). In the
fixupPhase we could patch the shebangs in $out/ to use the bash
interpreter that has
the pre-set PATH to all runtime deps of progA.

And the same should be doable for python/perl/ruby....

> 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.)

Your idea of buildInputs is the same as mine.

> 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?

runtimeInputs is different from propagatedBuildInputs. Maybe there
could be a propagatedRuntimeInputs though.

I think the nixpkgs manual describes propagatedBuildInputs best:

"""
Like buildInputs, but these dependencies are propagated: that is, the
dependencies listed here are added to the buildInputs of any package
that uses this package as a dependency. So if package Y has
propagatedBuildInputs = [X], and package Z hasbuildInputs = [Y], then
package X will appear in Z’s build environment automatically.
"""

Best regards,
Bjørn Forsman