Tiziano Müller wrote:
>>> 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).
Agreed, and that's why I like the out-of-band solution better (i.e.
header line with "# EAPI=42". No need for mangled filenames, and no
nead to actually source.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
