[Nix-dev] Re: $out/ENV?

Marc Weber marco-oweber at gmx.de
Sun Jun 6 18:03:28 CEST 2010


Excerpts from Yury G. Kudryashov's message of Sat Jun 05 07:44:01 +0200 2010:
> Marc Weber wrote:
> 
> > Now we could replace the buildenv.pl script by
> > 
> >   {
> >     for i in $paths; do
> >       cat $i/ENV
> >     done
> >   } >> $out/ENV
> > 
> > Thus: we don't have to create 10.000 symlinks. we could concatenate all
> > ENV files. In your .bashrc you could source it and be done.
> I object. The main problems with KDE on NixOS is that KDE stores some 
> /nix/store/... paths to ~/.kde/share/... With all file symlinked to 
> /var/run/..., we can patch KDE to not resolve paths, and store /var/run/... 
> This will survive after upgrade.

I'm aware of this. My "use evince to open pdfs" firefox setting depends
on a path being in ~/.nix-profile or /var/run/current-system/..

Same applies to user shell settings or whatnot.
So I don't want to change this. Maybe removing thome files could make
sense. But I don't want to discuss removing all.


> I propose another solution:
> 
> 1. $perl/etc/env.d/perl sets some variable that tells us "we want PERL5LIB 
> variable that aggregates $out/lib/perl5/site_perl for all needed outputs"
> 2. In build environment, we source all $dependency/etc/env.d/*, then 
> aggregate all needed variables for all dependencies.
> 3. In user env, we source all $profile/etc/env.d/*, then aggregate all 
> needed variables for all profiles.

I'm not sure whether you got the main points:

- you can make derivations export features rather than assuming at the
  end that all packages to have a $lib/perl5/site_perl path.
  Eg if a package has include files in $out/include/mysql
  you can add -I$out/include/mysql to NIX_CFLAGS_COMPILE instead of
  $out/include (which is currently done, thus mysql includes are not
  found)

- does this env.d/perl script prevent duplicate entries?
  - well it could

- can (should) your env.d/perl script be used in builder scripts?

> > You can choose whether to source your ENV file only or the system ENV
> > file as well. In other words: You can merge envs on the fly:
> > 
> > . ~joe/.nix-profile/ENV
> > . ~marc/.nix-profile/ENV
> > . ~other-user/.nix-profile/ENV
> Not useful until you can unload ENV.

Explain this please.

You can always start a subshell, add an env, then quit the shubshell.
You can always remove all environment vars and start sourcing those
files from scratch. So I don't see the point in thinking about how to
implement a "unload" feature.

So unless your env.d/perl script is used in builders it does'nt solve
the mess. It continues supporting it. By mess I mean that you have to
define vars such as PYTHONPATH and PERLLIB twice: In user environments
(eg .bashrc) and in build scripts. Having amendable ENV files would make
one of those efforts obsolete.

Marc Weber



More information about the nix-dev mailing list