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

[Michał Górny]

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.

-- 
Best regards,
Michał Górny