Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 06:14:23PM +1300, Kent Fredric wrote:
> On 13 March 2012 17:31, Brian Harring <ferringb@×××××.com> wrote:
> > Worse, it actually makes parsing _worse_ than it already is. ??What G55
> > had going for it was ease of filtering out unsupported eapi's.
> > Literally just filter the readdir results. ??This behemoth Zac is
> > proposing basically requires throwing regex at it, and *is* able to
> > be tripped up since eapi's aren't strictly integers (1-prefix,
> > 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> > likely non-greedy implementations of the regex).
>
> Eh? How? If you make "." a forbidden character in an eapi
> specificiation, and make "." the delimiter
>
>   dev-foo/foo-bar-2.3.4.eapi5.eb
>
> ^^^^
>
> How does that require regex?

That works; note however that wasn't what was proposed. ;)

Still is god awfuly fugly though, and reliant on digits as the first 
character to be readable.  Consider exheres: 

dev-foo/foo-bar-2.3.4.eapiexheres.eb 

Or arfrever's personal EAPI: 

dev-foo/foo-bar-2.3.4.eapi4-python.eb 

Etc.  This isn't an improvement, it's a regression in readability 
bordering on intentionally hating the developer who has to deal with 
it.


> remove the .eb  , and the last token remaining is the eapi .
>
> it doesn't clash with the existing system for 2 reasons, 1) the .eb
> extension   and 2)  "eapi5" is not a valid version token
>
> > Same angle, embedding it into the version space means that there can
> > be conflicts w/ PN.
>
> I'm confused as to how, can you give one theoretical example?

If you change the delimiter, it's not an issue; if it was left, 
consider dev-foo/blah-eapi2-1-eapi2.ebuild .  It's intentionally 
breaking it, but the point is that the issue *exists*, a problem that 
didn't before.  Change the delimiter and you can duck most of it 
although I suspect there still is a naggle or two.

That doesn't make parsing any prettier to implement however.


>   dev-foo/foo-bar-2.3.4.eapi5.eb  <-- eapi5 can't be a package name
> here, because its got the .eb suffix which means an EAPI *MUST* be
> specified
>
> and eapi5 also can't be a package name there, because then you're
> telling be it tokenizes as:
>
>     category=dev-foo
>     package=foo-bar-2.3.4.eapi5
>     version  = undefined
>     eapi      = undefined
>
> Which is clearly illegal.

Just a general point.  You changed the delimiter- meaning the 
failures mostly go away.  My points were against Zac's original 
proposal, thus arguing those points don't actually exist (swapping the 
delimiter) is a bit of a wrong way to argue- argue "change the 
delimiter and it goes away" rather than "nuh uh, there isn't an 
issue".  Way less confusing.


> > Basically... embedding it into the versioning like that, besides being
> > ugly as all hell, discards the main benefit g55 had- clear
> > identification of EAPI.
>
> It still seems "clear" to me.

"clear" means different things to different people.  For example, this 
code is actually clear to me:

class MockObject(dict):
  locals().update(
    ('__%sattr__' % x, getattr(dict, '__%sitem__' % x) for x in
    ('get', 'set', 'del'))

That code for everyone else is basically akin to eye-gouging w/ a 
follow up diddling of the new hole.  'Clear' is quite subjective being 
hte point.

EAPI mechanisms have to be designed for functionality, *and* ease of 
use for the general dev populace.  Having 

sys-apps/paludis-0.72.0-eapiexheres.ebuild

is *not* clearly parsable by the majority.  Were it parsable for the 
masses, that doesn't make it anything less than butt-fugly in my view.

If you really think it's great, convince others.  Ulm/Myself seem to 
view it fairly negatively, and I strongly doubt you're going to 
convince either of us to change those views.

~brian