Joe Peterson wrote:

> Ciaran McCreesh wrote:
>> And a file extension is far less obscurely complex than enforcing
>> arbitrary syntax restrictions upon ebuilds.
> 
> I disagree.  One is exposed to devs only as ebuild syntax; the other is
> exposed in an inappropriate location to everyone looking at the portage
> tree.
> 
>> No it can't. EAPI has to be known before the source can start. Bash
>> doesn't provide traps for executing code upon changed variables.
> 
> Doing it out-of-band solve this.
> 
>> No, it's only needed once per non-trivial change. So we might as well
>> just change it for every EAPI.
> 
> Huh?  If the "new" portage knows how to determine the EAPI definitively
> (and that would be defined), it can deal with the differences.
> 
>> And then how do we deal with EAPI 3, where the syntax changes again?
> 
> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
> from there.  If you change the way you declare EAPI each time, yeah,
> that's a problem, but I'm not sure why that would ne necessary.
No, that is not the problem.

Example:
In EAPI 42 we define that the package manager must provide a global function
extract_depend_from_setup_py() such that it is callable at a global level
in an ebuild like this

*snip start*

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=42

DESCRIPTION="A library aiming to support agile and test-driven python
development on various levels."
SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"
HOMEPAGE="http://codespeak.net/py/"
KEYWORDS="~amd64 ~x86"
SLOT="0"
LICENSE="MIT"
IUSE=""

extract_depend_from_setup_py

*snip end*

Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.

With the EAPI in the filename tools now knowing EAPI-42 will either ignore
the above foo-1.0.ebuild-42 or mask it because they may identify the
EAPI-version without sourcing the ebuild.

And: No, just sourcing the ebuild and simply masking it because we can't
source it is a no-go (since you're abusing error-handling as a case
switch).


-- 
gentoo-dev@g.o mailing list