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

[Andres Loeh]

> I believe, however, that wrappers like the one used in the new Python
> expression are not it, because this approach is not flexible enough.

Can you elaborate on that? One reason why I currently tend to support
the wrapper approach is because it seems to be the most flexible
(albeit perhaps not the most comfortable for the novice user)
approach. What do you perceive
as inflexible about composing your own expression?

> The problem of building variants applies not just to Python libraries or
> Haskell libraries, it applies to all package that have some sort of
> exchangeable dependency. For example, consider an application that
> supports various regular expression libraries, say both libpcre and
> libtre. In Nix, that application can easily be built with either
> library, but how do you generalize the case of building *both*?

Sure. I'm only ever using the ghc example because it's the one I'm
most familiar with. But I'm actually grateful if you can point out
other similar situations, and I'm sure there are plenty.

> Similarly, a great many programs can be linked with glibc or dietlibc or
> any other implementation of libc. In Nix, we can easily switch C
> libraries by changing stdenv, but we cannot easily build all possible
> permutations, i.e. we cannot easily build everything with every
> available libc.

Yes.

> Maybe I'm just missing an obvious insight, but I don't understand how
> the wrapper code found in the new Python expression improves that
> situation, even if it's just for Python. Let's say I want to build
> "cheetahTemplate" with both Python 2.5 and Python 2.6. How is that
> supposed to be done?
>
> My impression is that the recently added "override" feature is the way
> to go in that area.

Not sure here.

My impression is that the perceived inflexibility comes mainly because we
rely on all-packages.nix as making more-or-less fixed combinations for us,
and nix-env only being able to install constants into profiles.

I believe that nix-env's limitation to constant expressions is a dead end.
In the short term, as Nix(OS) currently mainly attracts expert users anyway,
I'm in favour of actually doing the composition that all-packages.nix usually
performs yourself. I'm using this on a relatively small scale with
some success now for a while. I.e., for quite many things I'm writing
my own little Nix expressions (that are importing and modifying
all-packages.nix) and put them in .nix files underneath
~/.nix-defexpr. In the longer term, I'd like to see nix-env or some
other tool support the composition of nix expressions from building
blocks that are provided from a library.

Cheers,
  Andres