Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that a regex is not required during the scan, and nor is restricting it to the first N lines, though the latter may be desirable and could trivially exclude comment and whitespace-only or empty lines.
Ciaran McCreesh wrote: >Michael Orlitzky wrote: >> Fair enough, but aren't you arguing the opposite point with Zac? If >> ebuilds are data, fine, we write EAPI=4 somewhere and be done with >> it. Anything not having that format is out-of-spec. > > The problem is that right now there's no way to determine the format of > the data until you already know the format of the data. Well, we know it's bash.. ;) > We hack around > this by not allowing "drastic" format changes, where "drastic" includes > "using things in newer versions of bash" and "not adding new global > scope commands". > > The question under discussion is whether we a) keep "what format the > data is in" as being part of the data, but impose some strange and > arbitrary conditions on it Stipulating an allowed set of characters is in no way arbitrary, nor strange- we already have similar restrictions on category and package names, versions, keywords and USE flags, for example. Requiring that the EAPI assignment for a bash .ebuild must be a literal (ie EAPI="foo" or EAPI=foo or EAPI='foo') at the start of a line, is not hard to understand; as you said ebuild authors already have to deal with lots of other subtle restrictions. As Marc Schiffbauer said, EAPI "might be the most important constraint in an ebuild at all" (from this and earlier discussion, it's clear that it definitely is) -- ebuild developers have to know about it, and this is a simple, clear restriction. Michał Górny stated: "The most important ebuild variables like EAPI should be readable on sight, without having to lookup random variables, functions etc" and in fact, all ebuilds in the tree already use a string literal- it just makes more sense from a code readability pov, quite apart from anything else. You mentioned indentation in another mail; afaics there is no problem with whitespace at the start of the line. Ensuring EAPI declaration and sourced value match, has value beyond use in EAPI extraction: it's a sanity check that should be performed in any case, way before an ebuild hits the tree. > , b) make a one-time change to have some kind > of 'header' inside the file describing its format that isn't really part > of the data itself, or c) admit that GLEP 55 already solved the problem > and we might as well just fix the issue properly once and for all, even > if GLEP 55's author is considered by some to be one of Satan's little > minions. > Regardless of your past behaviour, my objections to GLEP 55 are, and always have been, technical: it breaks encapsulation, which once implemented cannot be taken back. It results in a mess of filename extensions, which are confusing and irrelevant to end-users, as well as making other tools and scripts trickier to implement; a simple example: a highlighting editor would need to pattern-match the file extension. It's not needed: the simplest, least-invasive alternative already works, and should have been adopted years ago, when the Council asked for alternatives to be tried. The tree is clearly in shape to do so now, though. Package versions have to be in the filename to avoid collisions, and indeed the information is relevant to both end-users and developers. EAPI, while vital to the mangler and of immediate concern to developers, matches neither of those. Since it is of immediate concern, restricting it to a string literal makes sense from both maintenance (which is why it matches tree- usage) and implementation perspectives. And specifying what characters are allowed is a no-brainer; it's odd that that still has not been done, despite it also being a requirement for embedding EAPI in filenames. Your motivation for GLEP-55 states: "In order to get the EAPI the package manager needs to source the ebuild." Given a suitable specification, that isn't the case. repoman checks and explicit documentation are all that's needed beyond that. As for non-bash ebuilds, I have always agreed with antarus that they should simply use a different extension. Adding a new extension per source language is a *lot* cleaner than one per EAPI. Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
