| 1 |
Second patch containing only the ebuild.sh change. |
| 2 |
Answers to suggestions inline. |
| 3 |
|
| 4 |
On Thu, Sep 11, 2014 at 12:49 PM, Zac Medico <zmedico@g.o> wrote: |
| 5 |
|
| 6 |
> On 09/11/2014 04:18 AM, Bertrand Simonnet wrote: |
| 7 |
> > Hi guys, |
| 8 |
> > |
| 9 |
> > I have been working on a patch to make package.env (and env/ files) |
| 10 |
> > stackable with the profiles. |
| 11 |
> > The main goal would be to have a mechanism to be able to define a |
| 12 |
> > per-package, per-profile environment in a simple way. |
| 13 |
> > |
| 14 |
> > We can currently do this with profile.bashrc but we have to add some |
| 15 |
> > logic there to decide which package are relevant which already exist in |
| 16 |
> > ebuild.sh and pym/*. |
| 17 |
> > |
| 18 |
> > I attached my current patch which contain two main modifications: |
| 19 |
> > - ebuild.sh walk the profile and source all scripts with path: |
| 20 |
> > ${profile_path}/env/${category}/${PN} |
| 21 |
> > - config.py imports package.env from all profiles and then from |
| 22 |
> > /etc/portage/package.env |
| 23 |
> |
| 24 |
> It seems like duplication of work, to load the per-package env in |
| 25 |
> _grab_pkg_env on the python side, and to source it again on the bash |
| 26 |
> side. Why load the environments in both places? Note that the python |
| 27 |
> getconfig function only supports variable settings (no executable code), |
| 28 |
> which is very limited to what can be done when sourcing the files in bash. |
| 29 |
> |
| 30 |
> Right. |
| 31 |
The python part was mostly useful from a reuse point of view (write few |
| 32 |
scripts |
| 33 |
and enable them for some packages only. As the python mechanism is less |
| 34 |
powerful |
| 35 |
than I thought, I removed it. |
| 36 |
|
| 37 |
|
| 38 |
> > Note: |
| 39 |
> > * I gated the env/$CATEGORY/$PN scripts with a new feature: |
| 40 |
> per-profile-env. |
| 41 |
> > I couldn't do this with package.env as the scripts are parsed before |
| 42 |
> > we initialize self.features. |
| 43 |
> > * I am not particularly attach to both package.env and |
| 44 |
> > env/$CATEGORY/$PN. It might make more sense to have only |
| 45 |
> > env/$CATEGORY/$PN, especially considering the problem with package.env. |
| 46 |
> > |
| 47 |
> > Do you have any suggestions on this patch ? |
| 48 |
> |
| 49 |
> 1) If you want both the python-side env loading and the bash-side env |
| 50 |
> loading, I would make those into separate features, since sourcing the |
| 51 |
> files in bash supports full bash syntax while the python-side getconfig |
| 52 |
> function does not. |
| 53 |
> |
| 54 |
Fixed: removed the python part completly |
| 55 |
|
| 56 |
2) When adding new global functions in ebuild.sh, please unset them |
| 57 |
> inside bin/save-ebuild-env.sh, when internal functions are stripped from |
| 58 |
> the environment. |
| 59 |
> |
| 60 |
Done. |
| 61 |
|
| 62 |
|
| 63 |
> 3) You might want to look into using the repository's |
| 64 |
> metadata/layout.conf profile-formats setting, as an alternative to using |
| 65 |
> FEATURES to control profile-related behavior. |
| 66 |
|
| 67 |
I replaced the FEATURES gate by a profile-formats option. |
| 68 |
I added some logic to find layout.conf for a given profile path. (find the |
| 69 |
first |
| 70 |
parent dir named profiles then check ../metadata/layout.conf) |
| 71 |
Is there a corner case that I missed? |
| 72 |
|
| 73 |
> Would you be willing to accept this patch once the few problems are |
| 74 |
> > sorted out ? |
| 75 |
> |
| 76 |
> I can't speak for everyone, but I'm pretty sure we can work something out. |
| 77 |
> -- |
| 78 |
> Thanks, |
| 79 |
> Zac |
| 80 |
> |
| 81 |
> |
| 82 |
Thanks, |
| 83 |
Bertrand |
Archives