From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-python+bounces-208-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id BA5871381F3
for <garchives@archives.gentoo.org>; 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 <gentoo-python@lists.gentoo.org>; Sun, 11 Nov 2012 06:29:21 +0000 (UTC)
Received: by mail-vc0-f181.google.com with SMTP id n11so5397034vch.40
for <gentoo-python@lists.gentoo.org>; 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: <mailto:gentoo-python@lists.gentoo.org>
List-Help: <mailto:gentoo-python+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-python+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-python+subscribe@lists.gentoo.org>
List-Id: Discussions centering around the Python ecosystem in Gentoo Linux <gentoo-python.gentoo.org>
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: <CAB9SyzRNfsmNSssaGDxn-o9B5NRWwNoEL+qaB59RGtmZT4aUww@mail.gmail.com>
Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies
From: Ben de Groot <yngwin@gentoo.org>
To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org>
Cc: gentoo-python <gentoo-python@lists.gentoo.org>,
Gentoo Python Project <python@gentoo.org>
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 <mgorny@gentoo.org> 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
<div class=3D"gmail_extra"><div class=3D"gmail_quote">On 11 November 2012 0=
0:43, Micha=C5=82 G=C3=B3rny <span dir=3D"ltr"><<a href=3D"mailto:mgorny=
@gentoo.org" target=3D"_blank">mgorny@gentoo.org</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">
Hello,<br>
<br>
As some of you are aware already, there is a significant difference<br>
in handling Python implementation choice between python.eclass<br>
and python-r1 / p-d-ng.<br>
<br>
The python.eclass packages use USE_PYTHON (undocumented variable)<br>
or the eselected Python2+3, and store that choice implicitly.<br>
Everything works on the assumption that implementations don't change<br=
>
or user runs python-updater.<br>
<br>
The python-r1 / p-d-ng packages use explicit USE flags to choose<br>
implementation. The choice is thus explicitly exported and other<br>
packages can use USE dependencies to enforce matching implementations.<br>
<br>
The problems arise whenever python-r1 package depends on package using<br>
the python.eclass, or the other way round. There is no clear way to<br>
enforce the same implementations being used, so everything falls down<br>
to user.<br>
<br>
In order to solve the most common problems due to that, I have<br>
published a news item explaining how PYTHON_TARGETS work and what needs<br>
to be done with them.<br>
<br>
In the discussion with other Gentoo Python devs, it was assumed that<br>
USE_PYTHON should not be considered public and thus not be described<br>
in the message. Sadly, it seems that this resulted in people actually<br>
trying to disable Python3 using PYTHON_TARGETS and seeing random<br>
failures due to python.eclass enforcing it anyway.<br>
<br>
<br>
I believe we should thoroughly think what should be done now in order<br>
to solve the issues best for the transition time. Here are a few<br>
solutions I can think of.<br>
<br>
1) lard both eclasses with USE_PYTHON <-> PYTHON_TARGETS consistency<=
br>
checks. This should be pretty easy for python-r1, harder for<br>
python.eclass (anyone volunteering to touch it in thick gloves?).<br>
<br>
In other words, we just warn users whenever they need to do something<br>
to ensure things work.<br>
<br>
<br>
2) make python.eclass respect PYTHON_TARGETS.<br>
<br>
Sadly, due to PMS limitations we can't tell if PYTHON_TARGETS was set<b=
r>
by user or has the default value. So we either can:<br>
<br>
a) stop using USE_PYTHON and eselect defaults, start using<br>
PYTHON_TARGETS only, pull in correct Python versions, tell users to run<br>
python-updater;<br>
<br>
b) prefer PYTHON_TARGETS over USE_PYTHON and the default (but only<br>
if PYTHON_TARGETS !=3D default PYTHON_TARGETS, so we're on thin ice her=
e).<br>
<br>
<br>
3) make python.eclass respect and export PYTHON_TARGETS in IUSE.<br>
<br>
Like the above but instead of running the fragile and broken<br>
python-updater, we simply force rebuild of all packages. People can<br>
start using USE-deps in the meantime, everyone becomes a bit happier<br>
in the further plane. Sadly, this means every Python package is going<br>
to need being rebuilt.<br>
<br>
<br>
Please also note that 2 & 3 mean mass-changing behavior of stable<br>
packages. Not something I'd do in a short timeframe where the issue<br>
should be best fixed.<br>
<br>
Any other ideas? Any +1, -1s?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Best regards,<br>
Micha=C5=82 G=C3=B3rny<br>
</font></span></blockquote></div><br>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.<br>
<br>I think it is easiest to tell users to set USE_PYTHON as well, until py=
thon.eclass is finally phased out.<br clear=3D"all"><br>-- <br>Cheers,<br><=
br>Ben | yngwin<br>Gentoo developer<br>Gentoo Qt project lead, Gentoo Wiki =
admin<br>
</div>
--bcaec54b46c419ee4f04ce324e96--