[Nix-dev] Re: Some missing build-env features

[Yury G. Kudryashov]

Marc Weber wrote:

> Hi Yury,
> 
> I had in mind using env vars only earlier. I gave up on it because it
> would have meant rewriting nixpkgs.
> 
> But you only want some env vars.
> 
>> 4) A package should be able to tell buildEnv about required environment
>> variables. Examples: KDEDIRS, XDG_*, *_PLUGIN_PATH etc.
> 
> KDEDIRS etc, could they be simple set by /etc/bashrc pointing to
> ~/.nix-profile and /var/run/current-system/sw ?
Currently nixos bashrc has a few hardcoded env vars (KDEDIRS etc.). I think 
that buildEnv script should write, say, $profile/etc/environment that sets 
required env vars. Something like:

KDEDIRS=""
for i in ${NIX_PROFILES}; do
	KDEDIRS=$i${KDEDIRS:+:}$KDEDIRS
done

May be, needs adjustment to be more portable. Then "global" bashrc should 
source these files for each profile.

>> 2) A package should be able to tell buildEnv to execute some commands
>> after symlinking dirs&files. Example: update-mime-info etc.
> How should this be implemented? Would adding a
> ~/.nixpkgs/post-install-hook.sh suffice? It could run
> ~/.nix-profile/post-install-hooks/* which could be created by packages
> or such.
> 
> This should be run whenever you run
>   nix-env -switch-generation
>   nix-env -i
> etc
No, I was talking about commands that should be run in buildEnv post-build 
hook. Again, example: update-mime-info.
> 
> Excerpts from Yury G. Kudryashov's message of Fri Oct 08 16:10:07 +0200
> 2010:
>> 1) Currently a runtime dependency must be a build time dependency as
>> well. This is bad because there are cycles.
> 
> Can you elaborate ? You didn't reply to my last reply about this issue
> about creating an expression depending no both packages.
> How would you describe those cycles?
a = { passthru.propagatedUserEnvPackages = [ b ]; }
b = { passthru.propagatedUserEnvPackages = [ a ]; }

> 
> What would be wrong with an implementation like this?
> 
> addRuntimeDependency pkg: runtimeDeps: =
>  // now symlink pkg into $out and add runtimeDeps to
>  // propagatedBuildInputs
How many wrappers like this should I create? What if some propagations are 
optional (i.e., should be added only if some feature is requested)?
> 
> Marc Weber