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
signature.asc
Description: PGP signature
