From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SYH7v-0004Uv-3G for garchives@archives.gentoo.org; Sat, 26 May 2012 13:33:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5CBB4E05B4; Sat, 26 May 2012 13:33:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 245B7E05B4 for ; Sat, 26 May 2012 13:33:47 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id AAB391B4005 for ; Sat, 26 May 2012 13:33:46 +0000 (UTC) Received: by pbbrr13 with SMTP id rr13so3374729pbb.40 for ; Sat, 26 May 2012 06:33:45 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Received: by 10.68.138.161 with SMTP id qr1mr8050844pbb.37.1338039225491; Sat, 26 May 2012 06:33:45 -0700 (PDT) Received: by 10.143.90.9 with HTTP; Sat, 26 May 2012 06:33:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 May 2012 09:33:45 -0400 Message-ID: Subject: Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass From: Mike Gilbert To: Nikolaj Sjujskij Cc: gentoo-python Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: de7677e7-70b8-4859-bd66-9e2132394bd9 X-Archives-Hash: ec82a5a38d26535e723bc0549843e7c4 On Sat, May 26, 2012 at 9:01 AM, Nikolaj Sjujskij wr= ote: >> 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. > > =C2=A0Let's take a "stable" user who updates (`emerge --update --deep --n= ewuse > @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 us= ing > 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. > =C2=A0I 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.