Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Michał Górny]

On Sat, 26 May 2012 13:32:30 +0400
Maxim Koltsov <maksbotan@g.o> wrote:

> I want to say that I personally don't want to use python-distutils-ng
> in its current state and I know several active python ebuild writers
> that are not Gentoo developers and they don't want to use it too.
> First of all, how well is this eclass adapted to packages not using
> distutils? Old eclass had set of convenient functions
> (python_execute_function, python_generate_wrapper_scripts,
> python_conver_shebangs). I see some functions like these ones in new
> eclass, but can they serve as good replace and is their API public and
> stable?

We're planning on splitting some basic 'python' eclass out of it. Just
someone needs to do that, or I'll when I'll have more time and a good
plan.

> Then, we think that this ruby-ng style approach with PYTHON_TARGETS is
> a bit uncomfortable for end users and developers. This is going to be
> pain for all users if eclass gets used widely. Eclass allows developer
> not to set PYTHON_COMPAT and populate it with all available values —
> well, it's nice.

I think we can disable that early if new Python versions are likely to
introduce breakages.

> But imagine that Python 3.3 arrives. All ebuilds
> using new eclass will get new IUSE and therefore will be rebuilt
> during emerge --update --newuse world. That's hardly sensible. It's
> awful to rebuild packages which might be very 'heavy' just for
> nothing.

We don't support '--newuse' in Gentoo. People who do that are on their
own. We have enough problems to care about in our workflow.

> On the other hand, if developers are forced to set PYTHON_COMPAT, this
> will result in great delays in getting new python support to Gentoo.
> You can say that ruby-ng has the same behavior and nobody complains.
> But python is not ruby. Ruby 1.8 to 1.9 transitition was connected
> with a lot of incompabilities, so one could not assume that ruby-1.8
> package will work on 1.9. Python 3.2 to 3.3 transitition should be
> harmless and almost all packages will require no changes. So some
> implicit mechanism of doing this must be implemented.

I guess that 3.2->3.3 would include having python3_3 masked for
a longer while to test it.

-- 
Best regards,
Michał Górny