[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