Re: [gentoo-portage-dev] [PATCH] per package environment: generalize the mechanism to be profile specific

[Zac Medico]

On 09/11/2014 04:18 AM, Bertrand Simonnet wrote:
> Hi guys,
>
> I have been working on a patch to make package.env (and env/ files)
> stackable with the profiles.
> The main goal would be to have a mechanism to be able to define a
> per-package, per-profile environment in a simple way.
>
> We can currently do this with profile.bashrc but we have to add some
> logic there to decide which package are relevant which already exist in
> ebuild.sh and pym/*.
>
> I attached my current patch which contain two main modifications:
> - ebuild.sh walk the profile and source all scripts with path:
> ${profile_path}/env/${category}/${PN}
> - config.py imports package.env from all profiles and then from
> /etc/portage/package.env

It seems like duplication of work, to load the per-package env in
_grab_pkg_env on the python side, and to source it again on the bash
side. Why load the environments in both places? Note that the python
getconfig function only supports variable settings (no executable code),
which is very limited to what can be done when sourcing the files in bash.

> Note:
> * I gated the env/$CATEGORY/$PN scripts with a new feature: per-profile-env.
>    I couldn't do this with package.env as the scripts are parsed before
> we initialize self.features.
> * I am not particularly attach to both package.env and
> env/$CATEGORY/$PN. It might make more sense to have only
> env/$CATEGORY/$PN, especially considering the problem with package.env.
>
> Do you have any suggestions on this patch ?

1) If you want both the python-side env loading and the bash-side env
loading, I would make those into separate features, since sourcing the
files in bash supports full bash syntax while the python-side getconfig
function does not.

2) When adding new global functions in ebuild.sh, please unset them
inside bin/save-ebuild-env.sh, when internal functions are stripped from
the environment.

3) You might want to look into using the repository's
metadata/layout.conf profile-formats setting, as an alternative to using
FEATURES to control profile-related behavior.

> Would you be willing to accept this patch once the few problems are
> sorted out ?

I can't speak for everyone, but I'm pretty sure we can work something out.
-- 
Thanks,
Zac