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