Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-python
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Nikolaj Sjujskij <sterkrig@...>
From: Mike Gilbert <floppym@g.o>
Subject: Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 09:33:45 -0400
On Sat, May 26, 2012 at 9:01 AM, Nikolaj Sjujskij <sterkrig@...> 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.


Replies:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Nikolaj Sjujskij
References:
python-distutils.eclass vs. python.eclass + distutils.eclass
-- Maxim Koltsov
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Dirkjan Ochtman
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Nikolaj Sjujskij
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Next by thread:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Previous by date:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Next by date:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass


Updated Jun 01, 2012

Summary: Archive of the gentoo-python mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.