On Tue, Mar 13, 2012 at 06:14:23PM +1300, Kent Fredric wrote:
> On 13 March 2012 17:31, Brian Harring <ferri...@gmail.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
