On 09:39 Wed 27 Jul , Michał Górny wrote: > 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)?
Eclasses still shouldn't break backwards compatibility — that hasn't changed in the past 5 years, despite what a very small minority of devs appears to think. This has been a huge PITA for python.eclass in particular, which has broken tons of my ebuilds for no particular reason. (And no, a 30-day warning is not an excuse for breaking anything.) If you need to edit an eclass for EAPI/API changes anyway, updating the inherit line to "python-2" instead of "python" isn't a big deal. In the general sense, I think changing the API in arbitrary ways based on the EAPI in use is just plain confusing, and it should go into a new version-bumped eclass instead. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com
pgpgLBfaNeoHa.pgp
Description: PGP signature
