[Nix-dev] [***SPAM***] Dynamic Dependency Management by Calling External Programs from Nix

[Vladimír Čunát]

Hi everyone.

On 25 October 2011 01:35, Shea Levy <shea at shealevy.com> wrote:
> For the most part, the nix expression language is extremely good at
> expressing the dependency relationship between derivations. Unfortunately,
> there are some cases where the requirement that the information required to
> resolve dependencies can only come from pre-existing text files (either
> through importing other nix expressions or builtins.readFile) leads to some
> real problems.
> ...
> Thoughts?

After the Haskell+Python discussion, I believe that some kind of
dependency solver would find its use *in* the nix language.
So far all the dependencies were explicit and in places where more
versions/configurations were needed, a function was called several
times. It works quite fine and goes well with the policy of minimizing
the number of maintained variants, but as we saw it doesn't integrate
well with third-party repositories like hackage. For the packaging
systems I saw, it's always some kind of database of packages where
each version has some dependencies and configuration options and
there's install-time dependency resolution (I've got most experience
with Gentoo's emerge and paludis).

I also agree with Marc that it might be useful to have some kind of
on-demand expression generation - for example Hackage is a really
large database and it might be too costly to always parse the
expression generated from it (maybe separation into an included file
would help, I don't know). Even store-dependent expressions seem to be
needed, although I would avoid this whenever possible. Moving the
expression towards a lazy database-type searching could be another
possibility of speeding things up - most evaluation time is IMO taken
by looking up derivation of a given attrname/name (parts of the
database could be downloaded from hydra first time they are needed, so
we could avoid the space overhead).

Vlada