List Archive: gentoo-python
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sat, 26 May 2012 13:32:30 +0400
Maxim Koltsov <firstname.lastname@example.org> 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
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
> 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
> 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
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.