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--