[Nix-dev] User environment hooks . o ( started dreaming / don't know )

Marc Weber marco-oweber at gmx.de
Mon Oct 13 13:11:11 CEST 2008


> >>   nix-env -qa 'ghc-6.8.3/*'
> > :-) Why does it have to be a tree?
> Oh, it most certainly doesn't have to be. I didn't want to put too much
> in that mail.
Because its faster (-i vs -iA difference).. :-) - that's no real reason
I agree.

> This, in a way, is the point that Eelco also made. I can see that it is
> undesirable to have old package re-evaluated, i.e., rebuilt, without notice.
> I don't think, however, that the specific problem you describe is so bad.
> For instance, the ghc environment only has to be rebuilt whenever a ghc
> package actually changes, *not* for every other user environment change.
> Similarly for perl, java, and TeX.  You're suggesting that someone with
> 200 ghc library packages should imperatively maintain the user-specific
> package.conf file? That's not a good option either.
> 
> > I think having a derviation wrapping a compiler and libraries etc is
> > fine only for a specific domain (such as ghc) exactly for that reason.
> 
> I don't understand what you mean here? You say it *is* fine? Or only
> for ghc? What makes ghc different from TeX or firefox with plugins or
> ...?
Yes, it is fine if you limit it to Tex or ghc and libs or ...
But it'll start hurting you if you extend the instantiation of the whole
user environment because you don't have to parse 200 (ghc)libs, but say
600 packages (ghc * 2 + texlive or such). Eelco was right saying it's
unfortunate to have all packages replaced when adding one package.
I was not pointing out that detail, but that it would take nix-env a lot
time if it had to reevaluate all packages having been installed. That's
what I meant talking about a domain (either ghc or texlive or another
one)
> Yes. All the more reason to use wrappers. How do you install the same
> library for both compiler versions right now, if you don't use a wrapper?

Well, so we agree on that now that wrappers are teh way to go :-)

Sincerly
Marc Weber



More information about the nix-dev mailing list