On 03/09/12 10:05, Zac Medico wrote: >> >> Surely we can source one or two lines of the ebuild safely, like the >> example shows? > > Why would we though, when sourcing is a relatively costly operation, and > there are much more efficient ways to get the EAPI?
There do not seem to be any that people agree on =) I mean, it's /easy/ to get the EAPI. There's a list of ways on the GLEP, but all of them have trade-offs. The header comment seems to be the preference in this thread. The advantage that the eapi function has over a comment is that it's not magic -- it's just normal bash syntax. So we've addressed that issue at a small performance cost (we're really only sourcing the ebuild up to 'exit'). Whether or not that trade-off is worth it, who knows. I would prefer to make it work before we make it fast; but new ideas can't hurt considering nobody has agreed on an old one. > Also, you've got a chicken and egg problem, since you're assuming that > your eapi() function is going to be available in the global environment > when the ebuild is sourced. The whole point of knowing the EAPI in > advance is so that we will be able to make changes to the global > environment, such as add, remove, or change the behavior of _any_ function. Nah, at the top of the ebuild, you would have, EAPI=5 eapi 5 until package managers catch up, just like we would have to do with the comment. Once they've caught up, we can drop the EAPI= assignment, and begin using new features after the call to 'eapi'.
