Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long <slong@...> wrote:
>> 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.
> Ok: If we take this notion and enshrine it in stone:
> If we assume Bash 4 is a seperate language from Bash 3, as its
> syntax-backwards-incompatible, is it fair to suggest that for some
> future EAPI which require Bash 4, that the extension change to suit?
I don't agree that it's a separate language: a lot of work goes into keeping
BASH backward-compatible, so it's only when you use a new feature that your
script will no longer work on an older version. We dealt with the move from
bash2 to bash 3 quite well, I thought, and I don't see what's wrong with
stipulating support for a new BASH version in a new EAPI: that seems
quintessential use of the EAPI mechanism to me.
Another example would be use of extglob: as a scripting feature it needs to
be enabled before any of the functions or script using it are even parsed,
or BASH will bail with a syntax error. Specifying that it is so enabled in
an EAPI (which I believe was done a while back) allows the ebuild author to
use syntax that would otherwise fall over. Again, the EAPI mechanism works
fine, and there is no need for a different extension, even though the syntax
accepted has changed.
So we already have an example of where syntax changes, not just the
available environment, work with an EAPI inside the file, as it should be.
> ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the
> format is bash, and that '.ebuild4' is bash4 only?
> That way you have a forwards declaration of the syntax/file format
> required to parse the file, but no declaration of the EAPI, so you're
> not breaking encapsulation.
> This is breaking the direct file==eapi connection, but still
> maintaining a loose file<->eapi connection.
> Its /sort/ of like the "one time extension change" proposal, except
> its less 'arbitrary' than something like .eb , and it gives us the
> future option of changing the suffix again if bash 5 comes out with
> different syntax.
> Then we can do
> .ebuild = EAPI 0 - 4 & bash >= 3
> .ebuild4 = EAPI5 - 9 & bash >= 4
> .ebuild5 = EAPI10 - 15 & bash >= 5
As Brian said, you still need an EAPI mechanism, and further you've still
leaked metadata that simply doesn't need to be leaked. The only thing that
has ever held up adoption of EAPI extraction using a simple EAPI="foo"
declaration, matching tree-usage, is the fact that PMS does not specify
which characters are allowed in an EAPI name. This was asked for a couple of
years ago, iirc, and it is clearly necessary whether you scan for a token in
the ebuild, or you stick EAPI into the filename. (After all you are even
more restricted when you're talking about the filename, as opposed to a text
string given in a script.)
It just seems like a major hole in the spec, given that EAPI is so critical
to how you deal with the ebuild, and characters allowed for other tokens
such as category, package, version, keywords, USE-flags etc are specified.
It would be necessary for GLEP-55, but is not mentioned therein, which I
guess means the GLEP is under-specified as well.
.eapi-NN just strikes me as similar to having M$ Word format as .doc95
.doc2000 and the like- a complete mess. Or indeed sticking the charset
encoding (which has profound consequences when reading a file) from an HTML
file into its filename. Again, a similar, if not worse, piece of metadata--
just extracting it is hard if you don't know the charset in advance, but
I've never heard of anyone arguing that it should belong anywhere other than
in the file, from where tools dealing with it locally can extract it and,
say, emit the correct HTTP header.
What I was referring to with an extension-per-language would be something
like .pbuild for python-based build scripts, or .xbuild for your XML-
declarative example, and so on. In each case, you'd still need a supporting
infrastructure, but it's clear that you are using a completely different
setup, and it's no longer a traditional BASH-based ebuild. It would be quite
reasonable to suppose that you'd have EAPI specified there as well, since
you'd want to be able to add to and change the features you support over
time. Would you really want to change the extension each time you did,
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)