On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote: > I thought we had agreed that (1) with GLEP55 you have to source the ebuild > anyway (whereas the other proposal allows to just parse it to get at the > EAPI value) and (2) you can cache it sanely so that performance isn't the > issue?
You don't /have/ to source the ebuild to get the EAPI for GLEP 55. That section is only there to cover corner cases that some people wanted to be well-defined, and it could easily be removed if the consensus is that that isn't a problem. On the other hand, it could equally well be added to whatever alternative solution you might suggest. Consider the case where you have a foo-1.2.ebuild-4, and in the contents of the file it sets EAPI=5. What should that mean? There are three possibilities that I can think of: 1) It's illegal, don't do that. Then there's no need to source the file to find the EAPI, because the corner case should never happen, and if it does, the behaviour can be left undefined. 2) It's legal, and the ebuild has EAPI 4. Then there's no need to source the file to find the EAPI, because the EAPI in the filename always wins. 3) It's legal, and the ebuild has EAPI 5. This requires sourcing the ebuild to find the EAPI, and it's what GLEP 55 currently says. Now consider the alternative fixed-format "^EAPI=" suggestion. What if we have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 further down? What should that mean? The same three possibilities apply here as in the GLEP 55 case. If you think it should be illegal, or that it should mean EAPI=4, then there's no need to source the ebuild just to find the EAPI. If you think it should mean EAPI=5, then you do need to source the ebuild, exactly the same as in GLEP 55. Either way, this isn't a valid reason to choose the fixed-format alternative over GLEP 55, because the same concerns do or do not apply to both.
