[gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Brian Harring]

Hola folks.

Currently portage exposes a fair amount of it's internal 
implementation via vars/funcs into the ebulid env; this frankly makes 
it easier for ebuilds/eclasses to localize themselves to portage 
(rather than PMS), leading to breakage.

Thus a proposal for EAPI5 has been made, banning ebuilds/eclasses from 
using/accessing __, and requiring the PM to store it's internals in 
that namespace.

Basically, instead of portage doing thus:

is_function dyn_pkg_preinst && dyn_pkg_preinst

It does thus:

__is_function __dyn_pkg_preinst && __dyn_pkg_preinst.

Aside from avoiding accidental conflicts/usage, the standardized 
namespacing makes it a helluva lot easier to have repoman/qa tools 
look for bad usage.

Currently, there is a minor amount of ebuild/eclass usage of things 
named __*; ~90% of it is 'import once' eclass code like the following:

"""
if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_LIBTOOL="recur -_+^+_- spank
"""

Converting that is easy enough, and I'll be doing that work for 
gentoo-x86 if folks don't have an issue.

Note there is a few vars we need to exempt; that list is currently 
SANDBOX_* and FEATURES.  FEATURES is fine to exempt from this rule.

For SANDBOX_*, while that's a PM internal, that's a bit of a grey 
zone; regardless, we can actually address that via extending the 
sandbox functions a bit:

addwrite [-r|--remove] pathway # for example, to do a removal.

For instances where the sandbox needs to be turned off for a command- 
we do the same thing we did w/ nonfatal;

sandboxless <the command and args>

which is just
sandboxless() {
    SANDBOX_ON=0 "$@"
}

or SYDBOX_ON=0 (or their equivalent var) for sydbox usage.

Comments?
~harring

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Ben de Groot]

On 13 September 2012 04:36, Brian Harring <ferringb@gmail.com> wrote:
> Hola folks.
>
> Currently portage exposes a fair amount of it's internal
> implementation via vars/funcs into the ebulid env; this frankly makes
> it easier for ebuilds/eclasses to localize themselves to portage
> (rather than PMS), leading to breakage.
>
> Thus a proposal for EAPI5 has been made, banning ebuilds/eclasses from
> using/accessing __, and requiring the PM to store it's internals in
> that namespace.
>
> Basically, instead of portage doing thus:
>
> is_function dyn_pkg_preinst && dyn_pkg_preinst
>
> It does thus:
>
> __is_function __dyn_pkg_preinst && __dyn_pkg_preinst.
>
> Aside from avoiding accidental conflicts/usage, the standardized
> namespacing makes it a helluva lot easier to have repoman/qa tools
> look for bad usage.
>
> Currently, there is a minor amount of ebuild/eclass usage of things
> named __*; ~90% of it is 'import once' eclass code like the following:
>
> """
> if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_LIBTOOL="recur -_+^+_- spank
> """
>
> Converting that is easy enough, and I'll be doing that work for
> gentoo-x86 if folks don't have an issue.
>
> Note there is a few vars we need to exempt; that list is currently
> SANDBOX_* and FEATURES.  FEATURES is fine to exempt from this rule.
>
> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
> zone; regardless, we can actually address that via extending the
> sandbox functions a bit:
>
> addwrite [-r|--remove] pathway # for example, to do a removal.
>
> For instances where the sandbox needs to be turned off for a command-
> we do the same thing we did w/ nonfatal;
>
> sandboxless <the command and args>
>
> which is just
> sandboxless() {
>     SANDBOX_ON=0 "$@"
> }
>
> or SYDBOX_ON=0 (or their equivalent var) for sydbox usage.
>
> Comments?
> ~harring
>

I support this. It seems very sane.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Ulrich Mueller]

>>>>> On Thu, 13 Sep 2012, Brian Harring wrote:

> Note there is a few vars we need to exempt; that list is currently
> SANDBOX_* and FEATURES.  FEATURES is fine to exempt from this rule.
> 
> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
> zone; regardless, we can actually address that via extending the
> sandbox functions a bit:
> 
> addwrite [-r|--remove] pathway # for example, to do a removal.

As already discussed on IRC, a -r option may have undesired effects.
For example:

   addwrite /foo/bar
   # some commands writing to /foo/bar here
   addwrite -r /foo/bar  # try to restore previous state

Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it.

Maybe it's better to add a --{save,restore} option pair:

   addwrite --save /foo/bar
   # some commands writing to /foo/bar here
   addwrite --restore   # restore last saved state

or --{push,pop} to allow for nested calls, but maybe that would be
overkill.

> For instances where the sandbox needs to be turned off for a command-
> we do the same thing we did w/ nonfatal;
> 
> sandboxless <the command and args>

To start the bikeshedding: For some reason I associate "less (the
pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"?

Ulrich

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Mike Frysinger]

On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
> Currently, there is a minor amount of ebuild/eclass usage of things
> named __*; ~90% of it is 'import once' eclass code like the following:
>
> """
> if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_LIBTOOL="recur -_+^+_- spank
> """
>
> Converting that is easy enough, and I'll be doing that work for
> gentoo-x86 if folks don't have an issue.

pick a funner prefix and i approve

> For instances where the sandbox needs to be turned off for a command-
> we do the same thing we did w/ nonfatal;
>
> sandboxless <the command and args>

fine idea
-mike

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Mike Frysinger]

On Thu, Sep 13, 2012 at 1:48 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 13 Sep 2012, Brian Harring wrote:
>> Note there is a few vars we need to exempt; that list is currently
>> SANDBOX_* and FEATURES.  FEATURES is fine to exempt from this rule.
>>
>> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
>> zone; regardless, we can actually address that via extending the
>> sandbox functions a bit:
>>
>> addwrite [-r|--remove] pathway # for example, to do a removal.
>
> As already discussed on IRC, a -r option may have undesired effects.
> For example:
>
>    addwrite /foo/bar
>    # some commands writing to /foo/bar here
>    addwrite -r /foo/bar  # try to restore previous state
>
> Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it.
>
> Maybe it's better to add a --{save,restore} option pair:
>
>    addwrite --save /foo/bar
>    # some commands writing to /foo/bar here
>    addwrite --restore   # restore last saved state
>
> or --{push,pop} to allow for nested calls, but maybe that would be
> overkill.

not sure how your --save/--restore isn't a --push/--pop already

>> For instances where the sandbox needs to be turned off for a command-
>> we do the same thing we did w/ nonfatal;
>>
>> sandboxless <the command and args>
>
> To start the bikeshedding: For some reason I associate "less (the
> pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"?

sandboxoff
-mike

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Ulrich Mueller]

>>>>> On Thu, 13 Sep 2012, Mike Frysinger wrote:

>> Maybe it's better to add a --{save,restore} option pair:
>> 
>> addwrite --save /foo/bar
>> # some commands writing to /foo/bar here
>> addwrite --restore   # restore last saved state
>> 
>> or --{push,pop} to allow for nested calls, but maybe that would be
>> overkill.

> not sure how your --save/--restore isn't a --push/--pop already

--save/--restore would keep one saved state (which would be
overwritten with the next --save), whereas --push/--pop would maintain
a stack.

Ulrich

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Mike Frysinger]

On Thu, Sep 13, 2012 at 2:22 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 13 Sep 2012, Mike Frysinger wrote:
>>> Maybe it's better to add a --{save,restore} option pair:
>>>
>>> addwrite --save /foo/bar
>>> # some commands writing to /foo/bar here
>>> addwrite --restore   # restore last saved state
>>>
>>> or --{push,pop} to allow for nested calls, but maybe that would be
>>> overkill.
>
>> not sure how your --save/--restore isn't a --push/--pop already
>
> --save/--restore would keep one saved state (which would be
> overwritten with the next --save), whereas --push/--pop would maintain
> a stack.

that wouldn't really be any different than if you implement the -r
option like so:
 - `addwrite /foo` would always append the path regardless of
existence already in the variable
 - `addwrite -r /foo` would remove exactly 1 occurence

so if you don't want to do push/pop, let's stick with just adding a -r
flag and implementing things as described above as it makes dev's
lives simpler.
-mike

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[David Leverton]

On 13 September 2012 06:48, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 13 Sep 2012, Brian Harring wrote:
>> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
>> zone; regardless, we can actually address that via extending the
>> sandbox functions a bit:
>>
>> addwrite [-r|--remove] pathway # for example, to do a removal.

It's nice to be able to do
    local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits.  It's not the end of the world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.

>> For instances where the sandbox needs to be turned off for a command-
>> we do the same thing we did w/ nonfatal;
>>
>> sandboxless <the command and args>
>
> To start the bikeshedding: For some reason I associate "less (the
> pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"?

"sansbox"?  *flees*

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Ulrich Mueller]

>>>>> On Thu, 13 Sep 2012, David Leverton wrote:

> It's nice to be able to do
>     local SANDBOX_WRITE=${SANDBOX_WRITE}
> and then allow bash to restore the old value at the end of the
> function, regardless of how it exits.  It's not the end of the world
> to lose this, but it would be a bit of a shame IMHO - having to do it
> manually seems a little error-prone.

Maybe we should just document the SANDBOX_* variables? Looks like the
easiest solution to me.

The problem with adding an option to addwrite is that eclasses would
have to stick with the existing solution, or add a pointless case
distinction. Otherwise it won't work for all EAPIs.

Ulrich

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Brian Harring]

On Thu, Sep 13, 2012 at 01:53:21AM -0400, Mike Frysinger wrote:
> On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
> > Currently, there is a minor amount of ebuild/eclass usage of things
> > named __*; ~90% of it is 'import once' eclass code like the following:
> >
> > """
> > if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
> > ___ECLASS_ONCE_LIBTOOL="recur -_+^+_- spank
> > """
> >
> > Converting that is easy enough, and I'll be doing that work for
> > gentoo-x86 if folks don't have an issue.
> 
> pick a funner prefix and i approve

_LIBTOOL_ECLASS_GOT_SPANKED_ALREADY

Either that or one could just inject futurama quotes:

_LIBTOOL_ECLASS_DOESNT_WANT_TO_LIVE_ON_THIS_PLANET_ANYMORE

> > For instances where the sandbox needs to be turned off for a command-
> > we do the same thing we did w/ nonfatal;
> >
> > sandboxless <the command and args>
> 
> fine idea

withoutsandbox. ;)

Joke aside, 'nosandbox' is more consistent; also, there's basically 
one usage in the tree (virtualx) that would need it, although the 
level of ebuild usage for that, I do not know- donnie might, that was 
his code originally iirc.

~harring

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Mike Frysinger]

On Thu, Sep 13, 2012 at 4:32 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 13 Sep 2012, David Leverton wrote:
>> It's nice to be able to do
>>     local SANDBOX_WRITE=${SANDBOX_WRITE}
>> and then allow bash to restore the old value at the end of the
>> function, regardless of how it exits.  It's not the end of the world
>> to lose this, but it would be a bit of a shame IMHO - having to do it
>> manually seems a little error-prone.
>
> Maybe we should just document the SANDBOX_* variables? Looks like the
> easiest solution to me.
>
> The problem with adding an option to addwrite is that eclasses would
> have to stick with the existing solution, or add a pointless case
> distinction. Otherwise it won't work for all EAPIs.

well, if you want to focus on the $now, then you're mostly correct.
however, as we've done in the past, it's generally pretty easy to
implement functionality in say eutils.eclass so that other places
don't have to worry about different EAPI code paths.  then in the
$future, there is only the code provided by EAPI.
-mike