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

[Mike Gilbert]

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.