Gentoo Archives: gentoo-dev

From: "Jesus Rivero (Neurogeek)" <neurogeek@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
Date: Sat, 15 Oct 2011 12:49:06
Message-Id: CAD3zpDmpDfdnEJJeM8_0X7Z9H1WC1Ku2GwbRY7aSZAH_Zdw9hg@mail.gmail.com
In Reply to: Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying by Mike Gilbert
On Fri, Oct 14, 2011 at 9:54 PM, Mike Gilbert <floppym@g.o> wrote:
> On 10/14/2011 09:11 PM, "PaweĊ‚ Hajdan, Jr." wrote: >> On 10/14/11 5:38 PM, Alec Warner wrote: >>> I believe op's point is that there is no one to escalate the problem >>> to; certainly the council members are not going to do the work >>> themselves and we already have our best people on it. >> >> I'm aware of that. My point is that I think there are many scenarios in >> which EAPI-4 + python.eclass can work, especially if it's used only for >> few things in cases like www-client/chromium >> >> Because the python team takes _ages_ to do the transition that is >> holding back many other packages, because they've made python.eclass >> overly complex and now try to make it perfect, >> >> I'd just like to get an "OK" to enable EAPI-4 for that eclass. >> >> Please note that it's still up to dependent packages which EAPI they >> use. If they break python.eclass with EAPI-4 they shouldn't update to >> that EAPI. However, if there are packages using python.eclass that could >> work fine with EAPI-4, it shouldn't be blocking them for *ages* >> > > That would be an ok approach from my perspective: We could just change > line 14 of python.eclass and let package maintainers report breakage as > they increment EAPI. I am confident that nothing EAPI <= 3 would break. > > Is anyone (especially djc and the python herd members) opposed to this? > >
Sorry I wasn't able to post before. But... This can be done and in fact has been discussed before, just allow ebuild to not die with EAPI=4, but this doesn do anything at all, just not die on EAPI=4. All the features and the good stuff just won't be there as other use cases need (as Robin and Tony mentioned). We've been working on a redesign of the eclass but is nothing like stealing candy from a kid, there are many things involved, such as the large amount of Python ABIs that people use regularly, distutils quirks, current eclass complexity, among others that make it quite challenging to come up with something new. I'm all up for making eclass accept EAPI=4 ebuilds, but to fully implement EAPI=4 fesatures, I'm going to have to ask you guys for a bit of more patience. I know you have done just that, being patient, but just a bit more. I know we can deliver a solution for this soon enough. Best regards, -- Jesus Rivero (Neurogeek) Gentoo Developer