[gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
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
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
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? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos pa...@gentoo.org wrote: 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? AFAIK, the EAPI4 support in the overlay is EAPI 4-python, that almost certainly will never come to gx86, and some guys are trying to port the functionality to raw EAPI4, IIRC. Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
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
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
Donnie Berkholz schrieb: 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. I think making the eclass behave differently on new EAPIs is not a bad way to deprecate old functions. It will not break any existing ebuilds. Only if you touch the ebuild and change the EAPI things may break, but then the ebuild has your attention anyway. And there is no real disadvantage over a python.eclass that dies on EAPI 4 and a python-2.eclass that dies on EAPI =3 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On 27.07.2011 17:30, Chí-Thanh Christopher Nguyễn wrote: Donnie Berkholz schrieb: 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. I think making the eclass behave differently on new EAPIs is not a bad way to deprecate old functions. It will not break any existing ebuilds. Only if you touch the ebuild and change the EAPI things may break, but then the ebuild has your attention anyway. I agree there's no problem with small deprecations with new EAPIs as long as they are handled properly (it doesn't break backwards compatibility) so that ebuilds authors notice they must change things. If the eclass turns into a wholly different thing then it should rather be a new eclass. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On Wed, 27 Jul 2011 11:02:31 +0200 Pacho Ramos pa...@gentoo.org wrote: 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? AFAIK they are slowly merging patches from the overlay to gx86, reviewing them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On Wed, 27 Jul 2011 16:30:08 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Donnie Berkholz schrieb: 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. I think making the eclass behave differently on new EAPIs is not a bad way to deprecate old functions. It will not break any existing ebuilds. Only if you touch the ebuild and change the EAPI things may break, but then the ebuild has your attention anyway. That's one thing. Renaming variables and changing their formats is another one. And there is no real disadvantage over a python.eclass that dies on EAPI 4 and a python-2.eclass that dies on EAPI =3 What I'd prefer instead, is a python.eclass that just behaves in EAPI 4 like usual, and a new python-r1.eclass which has a clean API (and possibly supports EAPIs 2+ or so). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
Michał Górny schrieb: On Wed, 27 Jul 2011 16:30:08 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Donnie Berkholz schrieb: 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. I think making the eclass behave differently on new EAPIs is not a bad way to deprecate old functions. It will not break any existing ebuilds. Only if you touch the ebuild and change the EAPI things may break, but then the ebuild has your attention anyway. That's one thing. Renaming variables and changing their formats is another one. And there is no real disadvantage over a python.eclass that dies on EAPI 4 and a python-2.eclass that dies on EAPI =3 What I'd prefer instead, is a python.eclass that just behaves in EAPI 4 like usual, and a new python-r1.eclass which has a clean API (and possibly supports EAPIs 2+ or so). I fully support the idea of just adding EAPI-4 support to the python eclass without any API changes and doing those changes in e.g. python-r1 eclass. It was already very frustrating, when the python eclass created additional changes per EAPI, same for those forced EAPI moves. You should never need to learn the new behaviour of an eclass, just because you want to change the EAPI in your ebuild. Such changes should be done in a new eclass, which both means a clean start and no compromise due to existing behaviour in the python eclass and less trouble for users of such eclass, since they only have to know the normal EAPI changes. Just because Arfrever did such things to the python eclass, it still is no good idea and should not be continued. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
2011-07-27 15:07:54 Rafael Goncalves Martins napisał(a): On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos pa...@gentoo.org wrote: 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? AFAIK, the EAPI4 support in the overlay is EAPI 4-python, that almost certainly will never come to gx86, and some guys are trying to port the functionality to raw EAPI4, IIRC. python.eclass from python overlay supports EAPI=4. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
There are small changes between behavior in EAPI=3 and EAPI=4 in python.eclass in python overlay. The main change is improved syntax of PYTHON_DEPEND, which provides support for more situations and replaces PYTHON_USE_WITH* variables. 95 % of whole code in python.eclass is EAPI-independent, so there is no need for a new eclass. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ohloh statistics updated
On Mon, Jul 25, 2011 at 2:30 PM, Jeroen Roovers j...@gentoo.org wrote: [1] https://www.ohloh.net/p/gentoo [2] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary It appears they count rather more commits than does CIA - Manifest commits look to be the likely cause. Each user can setup an ignore list from the ohloh interface. don't know if there's a way to ignore files project-side. Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
