[Nix-dev] general design of nixpkgs - What about adding a dependency solver?

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/28/2010 04:38 AM, Marc Weber wrote:
> Does the current way of managing dependencies make sense?

Mostly.

> Example:
> Now the dependency hell is starting: Will something bad happen if gnome
> and pygtk have been compiled with a different gtkLibs version than gimp
> will be compiled with?

Been there - done this with WebKit.

> How to fix?
> 
> a) don't. Hope it works
> 
> b)
> make pygtk and gnome be a function taking an gtklibs
> argument?
> (This means a lot of manual maintenance)
> 
> c)
> Change default for gtkLibs in all-packages?
> This means I run the risk of breaking other existing packages. I don't
> want to test *everything* at the moment.
> 
> create a nixpkgs branch for c) only intentionally not trying to ensure
> that all other packages depending on gtkLibs still build?

d) make sure that all relevant packages support MakeOverridable or an
equivalent mechanism. Use deepOverride for recursively replacing the
arguments with relevant names.

> This solution works fine for user envs. But it doesn't work for
> systemPath in NixOS. Well it does: If you start putting store path into
> /etc/nixos/configuration.nix which have been built previously by 
> using a different (maybe incompatible) nixpkgs branch..

Not the best way to accomplish that.
"
let pkgsOldGtk = import /etc/nixos/nixpkgs-old-gtk {}; in
    [ pkgsOldGtk.firefox ]
"

> So is this a design weakness in nixpkgs?

We have a few things to improve about overridability of package options,
but things are better than you describe.

> What do you think about implementing kind of general dependency resolver which
> tries to do the right thing automatically?
> 
> Then you could write packages like gentoo, Ruby Gem users, Haskellers
> (Cabal) or Eclipse plugin writers are doing:
> 
> Give a list of dependencies once:
> 
>   RDEPEND="java? ( virtual/jre )
>           >=sys-devel/binutils-2.16.1
>           >=dev-libs/nss-3.12.3-r1
>           >=dev-libs/nspr-4.7.4
>           >=app-text/hunspell-1.1.9
>           >=media-libs/lcms-1.17
>           x11-libs/cairo[X]
>           x11-libs/pango[X]
>           xulrunner? ( =net-libs/xulrunner-1.9.0* )"
> 
>   DEPEND="${RDEPEND}
>           dev-util/pkgconfig
>           java? ( >=dev-java/java-config-0.2.0 )"
> 
> and press a "try find a solution" button.

Currently it is somewhat simpler to predict how the changes will
propagate than with this system...

One of the very reasons I use Nix is that I got fed up with creative
apt-get and yum solutions to simple upgrade situations.

Also, there are library inputs and just-command-line inputs (where
different versions for different dependencies are OK)..

> The basic Nix system is perfect: You can easily put a different system
> on top of it providing this "try finding a solution" task.
> 
> Moreover suddenly it is possible to package Eclipse dependencies and
> such.
> 
> I'm aware that this is not an easy task. However specifying a dependency
> list would make nixpkgs more modular and a lot of passing of arguments
> could be omitted in nixpkgs.

Passing arguments in Nixpkgs can be handled by deepOverride and
callPackage, in my opinion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMKIB5AAoJEE6tnN0aWvw3NcIIAIqjSwKRQ6ONTZ7BaikJKtn2
ad8xtd3xs61MDPcMBsfTQUbKkTMR0clPQuVTZwHXTAzbaR34QOIUhsxp1dCzmMCL
g0P7Qu7f/vvtHjqrTOLfFFyUbAI/8D8SC3qU4QJ8JNRs5PFLsvqiXMNqDX0cyggp
Qk+N1e1nHFM/T/brL/dxp9SsjIp0081xnqIR0PuYc5m6G0OQuFaQE/pN8oDS5F9/
L26kp8zYiQPz73SvVf75E0Q2h1fOTFx0DEowxu6AMCmFFf940f7IIzNLf8e8lCoZ
fG1NJSTKOLhMT9gAugD0HYP6htht6m6A+ehVQKA6mZ+lOWiANDRQEEYKj2LOd8Y=
=p1mq
-----END PGP SIGNATURE-----