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

[Andres Loeh]

On Fri, Oct 10, 2008 at 3:46 PM, Marc Weber <marco-oweber at gmx.de> wrote:
> About the info problem:
> I'd like to see this fixed, too. But it's getting more complicated:
> You do not only want the info files from pacakges you have installed,
> ,but also from packages the system provides (via extraPackages)..

Actually, this is another argument against hooks. The system environment
can change without user action, so ideally all "effects" of such a change
should be immediate, and not require user action either. On the other hand,
we know the path of the system profiles, so right now INFOPATH has the
correct setting. So what's the problem in this case?

> And what about other stuff such as autotools and those .am macro include
> paths etc? For now I've tried solving this problem by myEnv (see my last
> updat) which enables me to construct an environment similar to the one
> you get when building a package by running loadEnv <name> on demand.
> But that's no solution for info.

Some controlled way to simulate a build environment might be nice.
I'm not sure at all though what status your change has. Generally, I'd
appreciate if anything that's perceived to be a solution to a general
problem would be documented and announced as such on the mailing list.
Otherwise, we're likely to solve the same problems multiple times, and
it's also difficult to discuss the direction in which we're going then.

>>   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.

> I suggested using a tag list some time ago. So it could look like this
> meta = {
>  tags = [" ghc-6.8.3-lib","network","haskell"];
> }

Well. Just setting a meta attribute is most likely not enough, since
it affects the functionality of a value. Ideally, a ghc lib wouldn't
even be installable outside of a package list of a ghc, so it shouldn't
just be a call to stdenv.mkDerivation.

For searching alone and categorization, I completely agree that tags
are much superior to a hierarchical structure, and there should be a
large list of keywords for each package.

> Then you could do
> nix-env -i 'where "ghc-6.8.3-lib" in tags' or such..
>
> Shouldn't be hard to add kind of xpath enginge...
> ghc-*/../[foo=bar] :-P
> Damn, this could rally be useful and meta attributes could correspond to
> "attributes". Not sure when I would have used it in the past. My grep
> tool does a really good reliable and fast job [1]
>
> About your other point having still some old ghc libs laying when
> upgrading ghc:
>
> If the nix-env -i really was a derivation (not only an implicit
> one)... we would have to wait much longer.
> Actually we already have a clone in all-packages.nix  (called buildEnv)
> so if you like you can already use that instead of nix-env.. However
> you'll start noticing that it takes much longer because all the
> derivations have to be evaluated each time.
>
> If we start having 200 ghc library packages with full dependencies and
> the same for perl, java, tetex (Don't know what else you all have
> installed).. nix-env -iA will start taking unbearable long.
> And you have to make nix do this work only to install a tiny
> xorg.xmessage application or such.. ?

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
...?

> Aeh coming back to your statement:
> Why do you think having those libraries still laying around is bad ?
> I think you only say this because you have to tidy up manually
> occasionally. (And that's a point I love about nix, that the garbage
> collector can do that automatically)..

I'm saying this because I get an inconsistent user environment with
lots of garbage and no internal dependency handling.

> If you fear that you no longer can run ghci the design is wrong because
> I really want to be able to install two different ghc versions (and
> libs) at the same time (I already do so)..

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?

Cheers,
  Andres