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

Marc Weber marco-oweber at gmx.de
Tue Oct 25 21:32:56 CEST 2011


Excerpts from Vladimír Čunát's message of Tue Oct 25 20:59:35 +0200 2011:
> After the Haskell+Python discussion, I believe that some kind of
> dependency solver would find its use *in* the nix language.
SAT? (equinox p2 Eclipse plugins is using it). Complex, slow, but
perfect?

> 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.
It does: Peter is happy.

The difference to gtk/ and the like  is that Haskell has Cabal and that
Cabal provides a unique source of package information about version, source,
dependencies: the hackage index. That's why you can optimize more
compared to packaging kde/gnome/...  And that's why it should be done.


> 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
I have a different understanding: I wrote hack-nix because I feel that
generating .nix expressions on the fly does not scale well enough.
That's why I'm generating nix expressions using Nix languages on the fly
by nesting function calls only. hack-nix does not write
haskell-packges.nix - cabal2nix (Peters solution) does.
its because flag changes can change dependency information completely.
Thus for each target patches it might be necessary to write a new tree
of dependencies. Peter partially proofed me wrong showing that for most
packages this worst case does not happen often.
Maybe its because most other dependency systems can't cope with it so
the Haskell community tries to avoid such problems.

This depends on the format. if you'd store data in sqlite ...
Or put all versions of a given package name into a single file
then you only read the package and its dependencies. For ruby this works
fine.

So what about builtins.loadSqliteDatabase "path" ? ...
:-) hard to diff though.

I really should have a closer look at python. Eventually you can extract
more dependency information easily by running setup.py on each package.

Marc Weber


More information about the nix-dev mailing list