[Nix-dev] How a nix gui tool might look like? - what about derivation = { alsoInstall =

[Marc Weber]

> b) make the wrapper collect this information at runtime

Some more information about how this could work.

Each library installs it's packagedb (maybe containing dependencies ?)
to

$profile/libs/ghc-<version>/libname.packagedb

The ghc{,-pkg,i} wrappers scan this directory by using something like
this glob pattern: <their-own-location/../libs/ghc-<version>/*

So they know which packages are installed.

I guess using a small sh wrapper running exec at the end would result in
not too much overhead.

Basically we have this kind of dep graph:
GHC -> libA -> libB
        `-> libC

so you can't used libA without GHC, you can't use libB without
installing libA.

the libB->libA dependency can be expressed by adding both libs to the
libB package resulting in duplicated entries if we add another libD
depending on B and C.
We can't (yet) tell nix-env to automtaically install GHC when installing
libA (without forcing collissions)

Solutions to the also installing ghc problem:

        patch the env builder that it doesn't report collisions if the
        colliding files are symlinks to the same file (thus all libs
        could ship with it's own set of symlinks pointing to their ghc)

        Add something like mkDerivation {
                alsoInstall = [ ghc ];
        ]
        I'd prefer this solution because this means we can solve
        the libB -> libA dependency trouble as well this way
        libBDerivation = mkDerivation { alsoInstall = [libA ghc ]; };

Anyway when thinking about this haskell / ghc specific problem we should
keep in mind that this kind of relation is found a lot of times:
Eclipse -> plugins
C/C++ -> libs
python -> libs
...

But only ghc requires the libs beeing compiled with the same compiler
version AFAIK.

Marc Weber