[Nix-dev] Re: May I remove the old python code?

Andres Loeh andres.loeh at googlemail.com
Wed Jan 14 23:27:37 CET 2009


Hi Peter.

> Why not? Consider the following (fictional) package database:
>
>  {
>     python24 = import ../development/interpreters/python/2.4 { ... };
>     python25 = import ../development/interpreters/python/2.5 { ... };
>     python26 = import ../development/interpreters/python/2.6 { ... };
>     python   = python24;
>     cheetahTemplate = import ../tools/text/cheetah-template { inherit python; };
>  }

Nice example. Why do you not simply make it a function though:

{
  python24 = ...
  python25 = ...
  python26 = ...
  cheetahTemplate = {python} : (import ... { inherit python; };)
}

> Building Cheetah with both python 2.5 and 2.6 means instantiating the
> expression cheetahTemplate twice -- the 'python' attribute is overridden
> with 'python25' and 'python26' respectively. On the command line, this
> could be done quite easily, say:
>
>  nix-env --override python=python25,python26 -i -A cheetahTemplate

Similarly, nix-env could support passing function arguments:

nix-env --args python=python25,python26 -i -A cheetahTemplate

Although, I guess, for both cases the question arises in which scope
the python25,python26 are evaluated. The examples suggest the local scope
of the function/expression definition, but that seems a bit fragile.

> To me, this mechanism seems very powerful, because every single
> attribute can be overridden by the user, just like that.

I guess that's the difference. Overriding in principle works for
everything, function abstraction have to be foreseen. I think that on
one hand it's nice to be able to override everything, on the other
hand it's nice if you can see where the important points of choice
are. Functions allow the package writer to say "this is where I want
to support a choice".

> Anyway, I'm not a genuine Nix expert and it's likely that my notions are
> naive or flat-out wrong. This problem fascinates me, however, and I
> would be happy if someone has a better idea or can provide an insight as
> for what's wrong with this one.

Please. I think that there are only very few (if any) Nix experts. We
can only find a good solution if we're not afraid of thinking out
aloud. So I certainly encourage you to voice your ideas, and I hope
that others forgive me mine ;)

Cheers,
  Andres



More information about the nix-dev mailing list