Gentoo Archives: gentoo-python

From: Mike Gilbert <floppym@g.o>
To: Nikolaj Sjujskij <sterkrig@×××××××.com>
Cc: gentoo-python <gentoo-python@l.g.o>
Subject: Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 13:33:51
In Reply to: Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass by Nikolaj Sjujskij
On Sat, May 26, 2012 at 9:01 AM, Nikolaj Sjujskij <sterkrig@×××××××.com> wrote:
>> So I think the second part of this (x.y to x.y+1 transitions, in the >> Python world, are generally relatively smooth) invalidates your point >> in the first part: if the transitions are generally smooth, then yes, >> when Python 3.3 gets stabilized, I want all of my Python packages to >> be available from the 3.3 interpreter. > >  Let's take a "stable" user who updates (`emerge --update --deep --newuse > @world`) his/her system regularly. > Python 3.3 is released, added to Portage tree and eventually unmasked. > PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge > --newuse @world` on stable system suggests rebuilding of every package using > new eclass, because new (though disabled) USE-flags was added. And when > Python 3.3 is keyworded stable, hence bringing new default PYTHON_TARGETS, > user should now rebuild those packages once more, but now, at least, not > uselessly. >
This is why I do my world updates with --changed-use instead of --newuse. The package manager already has the ability to deal with such scenarios intelligently, you just have to let it.
>  I had written about problems with new eclass a couple of weeks ago here. > Not that anybody cares that now any user not caring about dev-lang/python > explicitly would get Python 2.7 and all his modules compiled twice for no > good reason (except "we can't think out more sensible default for new > eclass"). Whether or not does he *really* need Python 2.x or stable and > included-in-stage3 Python 3.2 suffices for him. >
I did not speak up in the previous thread, but here are some of the advantages to a use flag based approach (PYTHON_TARGETS): - Ability to express proper dependencies on dev-lang/python and between python packages. - Makes python-updater obsolete (I think). - Better support for binpkgs. The disadvantage is that you must maintain another variable in make.conf, or accept the default value that is assigned in the profile. Here is how I justify the current default value of PYTHON_TARGETS: Due to past decisions, python3.2 is installed by default on all amd64 and x86 systems, so having python3_2 enabled by default makes sense. However, there are many things do not work in python 3, so the python2_7 target is a necessity.


Subject Author
Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass Nikolaj Sjujskij <sterkrig@×××××××.com>