Luca Barbato wrote:
> Tiziano Müller wrote:
>> 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.
>>
>
> Check if exists a line EAPI=*$, if does and the rest of the string
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...
... and package managers which don't do that already still fail.
--
gentoo-dev@lists.gentoo.org mailing list
> Tiziano Müller wrote:
>> 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.
>>
>
> Check if exists a line EAPI=*$, if does and the rest of the string
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...
... and package managers which don't do that already still fail.
--
gentoo-dev@lists.gentoo.org mailing list