Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

[Pacho Ramos]

El mié, 27-07-2011 a las 09:39 +0200, Michał Górny escribió:
> Hello,
>
> As many of us already raged, the Python eclasses are delaying half
> a year with support of EAPI=4. The reason for that is not actually
> the lack of time or complexity of needed changes but willingness to use
> the new EAPI as an excuse to turn the eclass API upside down.
>
> The question I'm raising here: should eclasses be actually allowed to
> do *heavy* changes in their APIs in such cases? Or should the eclass
> maintainers create a new eclass instead (python-r1.eclass or so)?
>
> The main advantage I see in that is that devs are somehow forced
> to migrate their ebuilds as soon as they bump EAPI in them. Taking
> a look at a number of ebuilds still using git.eclass (instead of git-2)
> this is a serious advantage.
>
> On the other hand, I find this idea very unclear. Why should two
> ebuilds use completely different eclass variables just because they're
> using two different EAPIs? More importantly, why is a dev forced to do
> the migration in a random point when he/she wants to bump the ebuild
> EAPI? I'd like to remind you that python eclass is still hard to read
> for many of us.
>
> And why do we have to wait so long to use a new EAPI? We already had to
> fix a lot of ebuilds when old EAPIs were banned in Python eclasses. We
> wanted to bump the ebuilds to EAPI 4 then but the eclasses didn't
> support it. And now it still doesn't come with EAPI 4 support.
>
> And keeping two different EAPIs in a single eclass file means probably
> that older EAPIs are going to be banned at a random point once again.
> Devs will have to pro-actively migrate their ebuilds, overlays will
> break and so on. The usual procedure related to eclass removal wouldn't
> apply.
>
> So, don't you think it would be better to simply add EAPI=4 support to
> python eclass with no changes and start developing the new API in
> python-r1? Devs could migrate then at any point they want (and have
> time to!), and when Python team wants to get rid of the old eclass,
> the usual removal procedure will apply.
>

About the concrete case of python eclass, per Arfrever's comment in bug
report related with its eapi4 support, that support is already available
in overlay, but not yet merged to the tree (probably because of the
possible upcoming retirement of Arfrever :-/). What is preventing python
team to merge eclass from overlay?