From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BA5871381F3 for ; Sun, 11 Nov 2012 06:29:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72342E0369; Sun, 11 Nov 2012 06:29:22 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B4992E0369 for ; Sun, 11 Nov 2012 06:29:21 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id n11so5397034vch.40 for ; Sat, 10 Nov 2012 22:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CgFpwGYNZ0vOa6BP/7yVUHPi2exezakOz5ebbsyG2KA=; b=eMGgqMUAXR3jSuqrErfmeyKMe6ATT5dmM+wZNHZ6wOR0YoAvWydqBNqGj+EVGxoyHV 1UBesdzuif+4CMU+7MdjwSva+K99z9bRlEuGQs72EJA2/l4HurE8gi0wB2Vs6vRGX8n3 yWzZgERnQakOPsBJPEBwzycjx8w7YvxXuZV0eF+mmWUXjmnOuKz6jxr1VbQUYYWX9Tcm 1x6BNg4FzzeZJbn353t2q1N/X+LA1fneZW+WMeqvskuhPnd3hiHgoHHoC6TW6A8EehgO /j2wspewN0HmjBL5kvKGWb0W+k3aUD3cJS6XyYgp/A67uYqfoj6yDvTYymCi5PGbFesu piqg== 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.220.16.12 with SMTP id m12mr18663164vca.14.1352615360851; Sat, 10 Nov 2012 22:29:20 -0800 (PST) Sender: yngwin@gmail.com Received: by 10.58.4.169 with HTTP; Sat, 10 Nov 2012 22:29:20 -0800 (PST) In-Reply-To: <20121110174322.656f1d67@pomiocik.lan> References: <20121110174322.656f1d67@pomiocik.lan> Date: Sun, 11 Nov 2012 14:29:20 +0800 X-Google-Sender-Auth: 8YmS3EEnkxAXfR6U0HEDHQ7yFhE Message-ID: Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies From: Ben de Groot To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-python , Gentoo Python Project Content-Type: multipart/alternative; boundary=bcaec54b46c419ee4f04ce324e96 X-Archives-Salt: 5450e14c-9f95-4771-9c05-47bab29bb50d X-Archives-Hash: c77d82cbf399a10d30bc9aecf440cd0c --bcaec54b46c419ee4f04ce324e96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 November 2012 00:43, Micha=C5=82 G=C3=B3rny wrote= : > Hello, > > As some of you are aware already, there is a significant difference > in handling Python implementation choice between python.eclass > and python-r1 / p-d-ng. > > The python.eclass packages use USE_PYTHON (undocumented variable) > or the eselected Python2+3, and store that choice implicitly. > Everything works on the assumption that implementations don't change > or user runs python-updater. > > The python-r1 / p-d-ng packages use explicit USE flags to choose > implementation. The choice is thus explicitly exported and other > packages can use USE dependencies to enforce matching implementations. > > The problems arise whenever python-r1 package depends on package using > the python.eclass, or the other way round. There is no clear way to > enforce the same implementations being used, so everything falls down > to user. > > In order to solve the most common problems due to that, I have > published a news item explaining how PYTHON_TARGETS work and what needs > to be done with them. > > In the discussion with other Gentoo Python devs, it was assumed that > USE_PYTHON should not be considered public and thus not be described > in the message. Sadly, it seems that this resulted in people actually > trying to disable Python3 using PYTHON_TARGETS and seeing random > failures due to python.eclass enforcing it anyway. > > > I believe we should thoroughly think what should be done now in order > to solve the issues best for the transition time. Here are a few > solutions I can think of. > > 1) lard both eclasses with USE_PYTHON <-> PYTHON_TARGETS consistency > checks. This should be pretty easy for python-r1, harder for > python.eclass (anyone volunteering to touch it in thick gloves?). > > In other words, we just warn users whenever they need to do something > to ensure things work. > > > 2) make python.eclass respect PYTHON_TARGETS. > > Sadly, due to PMS limitations we can't tell if PYTHON_TARGETS was set > by user or has the default value. So we either can: > > a) stop using USE_PYTHON and eselect defaults, start using > PYTHON_TARGETS only, pull in correct Python versions, tell users to run > python-updater; > > b) prefer PYTHON_TARGETS over USE_PYTHON and the default (but only > if PYTHON_TARGETS !=3D default PYTHON_TARGETS, so we're on thin ice here)= . > > > 3) make python.eclass respect and export PYTHON_TARGETS in IUSE. > > Like the above but instead of running the fragile and broken > python-updater, we simply force rebuild of all packages. People can > start using USE-deps in the meantime, everyone becomes a bit happier > in the further plane. Sadly, this means every Python package is going > to need being rebuilt. > > > Please also note that 2 & 3 mean mass-changing behavior of stable > packages. Not something I'd do in a short timeframe where the issue > should be best fixed. > > Any other ideas? Any +1, -1s? > > -- > Best regards, > Micha=C5=82 G=C3=B3rny > I'm sorry if I missed something, but I don't see why USE_PYTHON should be considered not public. That has been the only mechanism until now (in combination with package.mask) to get a consistent system without redundant multiple python versions. I think it is easiest to tell users to set USE_PYTHON as well, until python.eclass is finally phased out. --=20 Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin --bcaec54b46c419ee4f04ce324e96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 November 2012 0= 0:43, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Hello,

As some of you are aware already, there is a significant difference
in handling Python implementation choice between python.eclass
and python-r1 / p-d-ng.

The python.eclass packages use USE_PYTHON (undocumented variable)
or the eselected Python2+3, and store that choice implicitly.
Everything works on the assumption that implementations don't change or user runs python-updater.

The python-r1 / p-d-ng packages use explicit USE flags to choose
implementation. The choice is thus explicitly exported and other
packages can use USE dependencies to enforce matching implementations.

The problems arise whenever python-r1 package depends on package using
the python.eclass, or the other way round. There is no clear way to
enforce the same implementations being used, so everything falls down
to user.

In order to solve the most common problems due to that, I have
published a news item explaining how PYTHON_TARGETS work and what needs
to be done with them.

In the discussion with other Gentoo Python devs, it was assumed that
USE_PYTHON should not be considered public and thus not be described
in the message. Sadly, it seems that this resulted in people actually
trying to disable Python3 using PYTHON_TARGETS and seeing random
failures due to python.eclass enforcing it anyway.


I believe we should thoroughly think what should be done now in order
to solve the issues best for the transition time. Here are a few
solutions I can think of.

1) lard both eclasses with USE_PYTHON <-> PYTHON_TARGETS consistency<= br> checks. This should be pretty easy for python-r1, harder for
python.eclass (anyone volunteering to touch it in thick gloves?).

In other words, we just warn users whenever they need to do something
to ensure things work.


2) make python.eclass respect PYTHON_TARGETS.

Sadly, due to PMS limitations we can't tell if PYTHON_TARGETS was set by user or has the default value. So we either can:

a) stop using USE_PYTHON and eselect defaults, start using
PYTHON_TARGETS only, pull in correct Python versions, tell users to run
python-updater;

b) prefer PYTHON_TARGETS over USE_PYTHON and the default (but only
if PYTHON_TARGETS !=3D default PYTHON_TARGETS, so we're on thin ice her= e).


3) make python.eclass respect and export PYTHON_TARGETS in IUSE.

Like the above but instead of running the fragile and broken
python-updater, we simply force rebuild of all packages. People can
start using USE-deps in the meantime, everyone becomes a bit happier
in the further plane. Sadly, this means every Python package is going
to need being rebuilt.


Please also note that 2 & 3 mean mass-changing behavior of stable
packages. Not something I'd do in a short timeframe where the issue
should be best fixed.

Any other ideas? Any +1, -1s?

--
Best regards,
Micha=C5=82 G=C3=B3rny

I'm sorry if I missed something, b= ut I don't see why USE_PYTHON should be considered not public. That has= been the only mechanism until now (in combination with package.mask) to ge= t a consistent system without redundant multiple python versions.

I think it is easiest to tell users to set USE_PYTHON as well, until py= thon.eclass is finally phased out.

--
Cheers,
<= br>Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki = admin
--bcaec54b46c419ee4f04ce324e96--