| 1 |
Michał Górny schrieb: |
| 2 |
> On Wed, 27 Jul 2011 16:30:08 +0200 |
| 3 |
> Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
| 4 |
> |
| 5 |
>> Donnie Berkholz schrieb: |
| 6 |
>>> Eclasses still shouldn't break backwards compatibility — that |
| 7 |
>>> hasn't changed in the past 5 years, despite what a very small |
| 8 |
>>> minority of devs appears to think. This has been a huge PITA for |
| 9 |
>>> python.eclass in particular, which has broken tons of my ebuilds |
| 10 |
>>> for no particular reason. (And no, a 30-day warning is not an |
| 11 |
>>> excuse for breaking anything.) If you need to edit an eclass for |
| 12 |
>>> EAPI/API changes anyway, updating the inherit line to "python-2" |
| 13 |
>>> instead of "python" isn't a big deal. In the general sense, I think |
| 14 |
>>> changing the API in arbitrary ways based on the EAPI in use is just |
| 15 |
>>> plain confusing, and it should go into a new version-bumped eclass |
| 16 |
>>> instead. |
| 17 |
>> |
| 18 |
>> I think making the eclass behave differently on new EAPIs is not a |
| 19 |
>> bad way to deprecate old functions. It will not break any existing |
| 20 |
>> ebuilds. Only if you touch the ebuild and change the EAPI things may |
| 21 |
>> break, but then the ebuild has your attention anyway. |
| 22 |
> |
| 23 |
> That's one thing. Renaming variables and changing their formats |
| 24 |
> is another one. |
| 25 |
> |
| 26 |
>> And there is no real disadvantage over a python.eclass that dies on |
| 27 |
>> EAPI 4 and a python-2.eclass that dies on EAPI <=3 |
| 28 |
> |
| 29 |
> What I'd prefer instead, is a python.eclass that just behaves in EAPI 4 |
| 30 |
> like usual, and a new python-r1.eclass which has a clean API |
| 31 |
> (and possibly supports EAPIs 2+ or so). |
| 32 |
> |
| 33 |
|
| 34 |
I fully support the idea of just adding EAPI-4 support to the python eclass without any API changes |
| 35 |
and doing those changes in e.g. python-r1 eclass. |
| 36 |
|
| 37 |
It was already very frustrating, when the python eclass created additional changes per EAPI, same |
| 38 |
for those forced EAPI moves. You should never need to learn the new behaviour of an eclass, just |
| 39 |
because you want to change the EAPI in your ebuild. Such changes should be done in a new eclass, |
| 40 |
which both means a clean start and no compromise due to existing behaviour in the python eclass and |
| 41 |
less trouble for users of such eclass, since they only have to know the normal EAPI changes. |
| 42 |
Just because Arfrever did such things to the python eclass, it still is no good idea and should not |
| 43 |
be continued. |
Archives