Alistair Bush wrote:
4) Parsing the ebuild. But what are we parsing?, lets not limit ourselves to bash, we might want to change languages completely. If it is bash, what version, what if EAPI is set multiple times, what if its set in an eclass.
How do you do this if you're getting EAPI from the filename? How do you set it multiple times? How do you set it in an eclass if you're getting it from the filename?
It seems like when we're talking about just putting the EAPI in a comment line on line x of the ebuild we're barraged with 47 ways that it will limit us, but when we're talking about EAPI in the filename suddenly we're not concerned with those limitations. If it helps maybe we need to split EAPI into two records - one that deals with how to fundamentally parse the file and find out the EAPI, and the other that implements everything else the EAPI does.
I will certainly concede that putting it inside the ebuild potentially breaks compatibility with existing package managers. That is certainly a downside to this approach. However, none of the other objections that have been raised appear to hold water. An EAPI in a filename is a blob of text that needs to be parsed out in one particular way with one set of system calls. An EAPI embedded in the file is a blob of text that needs to be parsed out in one particular way with one set of system calls.
And if backwards compatibility were a serious issue you could define a new ".ebuild2" file spec that incorporates the EAPI inside the file and current package managers would ignore it. Then you're not changing the file extension every time a new EAPI comes along, and the need to do so could be handled via future GLEPs. Or we could just delay implementation and clean up existing package managers and tell users to migrate.
