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

[Marc Weber]

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

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.

>   nix-env -qa 'ghc-6.8.3/*'

:-) Why does it have to be a tree?
I suggested using a tag list some time ago. So it could look like this 
meta = {
 tags = [" ghc-6.8.3-lib","network","haskell"];
}

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

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.

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

/me is looking into the future.. can you see it as well ? hehe
Excuse me, my mood just feels good at the moment, no need to change
anything here  :)

cu
Marc Weber

[1] 
( it only refreshes the cache if the revision has changed ..)
(  path                   |          name )

marc at mail: ~ ]$ nixGrepP.sh ghc
cachefile is /tmp/nix-caches/git-9d7f3d29f1c3cca5e49fb6bb275bd465511decfc-d41d8cd98f00b204e9800998ecf8427e-cache
refreshing cache ..done
ghc68executables.alex                  alex-2.2
ghc68executables.drift                 DrIFT-2.2.3
ghc68executables.flapjax               flapjax-source-20070514
ghc64                                  ghc-6.4.2
ghcboot                                ghc-6.4.2-boot
ghc66                                  ghc-6.6
ghc661                                 ghc-6.6.1
ghc682                                 ghc-6.8.2
ghcsAndLibs.ghc68.ghc                  ghc-6.8.2
ghcsAndLibs.ghc68.extra_src            ghc-6.8.2-src-extralibs.tar.bz2
ghcsAndLibs.ghc68.src                  ghc-6.8.2-src.tar.bz2
ghc                                    ghc-6.8.3