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 DEF2B1381F3 for ; Sun, 11 Nov 2012 07:52:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 870BBE0630; Sun, 11 Nov 2012 07:52:50 +0000 (UTC) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E2280E0630 for ; Sun, 11 Nov 2012 07:52:49 +0000 (UTC) Received: by mail-da0-f53.google.com with SMTP id g9so2229596dad.40 for ; Sat, 10 Nov 2012 23:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VhgOx8mprM/a8OtOZtYdDhSeGOVM+mTpdjPInqRc3Dk=; b=mne7m//AmpWNVNKDTH0GP5PFS22C6AXD4Joq23okIzjbNJSmrhv24Rs5pVotwJcbB4 FYacV/koFxfyrlo7+qhdziN4gEhictEad6LulGSPJMw2blC5N2Xm2xaxFIuVgofJNFhq pqedK2FEI43ytTzuMrp6AVDXhGcZyOWV5SntzPee/5WlED5yIBx9b23zrIfalqbJsLmb qx9V4yDJ5ZEXW+eZI1aCKJXPP+ome8VFQZFriIxLuGatZyFbIlVP0Z+gwZDBK0pdw0WE Gto+d+O7ldieEve0KfJB8B3DqriP5YBXj6UKFkOpZgjdFwC3RKKdclKAM4lEnMVrfOSC M1AQ== Received: by 10.68.247.134 with SMTP id ye6mr41157963pbc.69.1352620368753; Sat, 10 Nov 2012 23:52:48 -0800 (PST) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id se4sm2177558pbb.13.2012.11.10.23.52.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 23:52:48 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sat, 10 Nov 2012 23:52:48 -0800 Date: Sat, 10 Nov 2012 23:52:48 -0800 From: Brian Harring To: Micha?? G??rny Cc: gentoo-python@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies Message-ID: <20121111075248.GA23241@localhost.corp.google.com> References: <20121110174322.656f1d67@pomiocik.lan> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121110174322.656f1d67@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: b9a1ef80-1ec5-4b52-b0f4-21a2600f0ef5 X-Archives-Hash: ab02b8756142883a7abfb6e477aeca6e On Sat, Nov 10, 2012 at 05:43:22PM +0100, Micha?? G??rny 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. Honestly... if we care this much about USE_PYTHON, then we should use it, rather than PYTHON_TARGETS. Mind you, I'm aware someone ignored repeatedly being told "do not fucking use periods in the targets- it cannot be allowed as a use flag due to compatibility issues in profiles"- meaning we have to dig out of a mess that was foresaw, but such is life. Fixing USE_PYTHON is simpler than trying to get users to migrate to a new var, let alone keep those two vars in sync. To get there, we'd have to basically accept 2.6/2_6 in USE_PYTHON w/in python.eclass (a modification I will sort if others won't), have it spit warnings, then flip it to a USE_EXPAND target. Portage, fortunately, is lose in this department- you can have a USE_EXPAND target w/ invalid use chars in it. It's just not usable in use dependencies nor IUSE, making it a dead setting if it uses invalid chars. So... thus: 1) make python.eclass know of both forms of USE_PYTHON (with periods, without). 2) convert USE_PYTHON to a use expanded target 3) convert python.eclass to use it. I realize this deprecates/kills PYTHON_TARGETS; my intention here isn't to piss on the var you added, it's to choose the less disruptive option here- lesser of two evils. Starting from scratch, PYTHON_TARGETS would be fine- unfortunately we need to map existing users (and usage) from python.eclass into the replacement, constraining our choises a bit. Counter arguments? To be clear, this is the path I strongly suggest we take- if you can punch holes in the logic/arguments from above, I'd definitely back down, but the use of PYTHON_TARGETS here feels like we're setting ourselves up for unnecessary pain. Keep in mind not *all* of python.eclass notions/setup has to be chucked- we can translate certain parts of it across to ease developer/user pains. > 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; Just a note; we /never/ should listen to eselect defaults, only USE enforced configuration; I'm appreciative you've not replicated that python.eclass idiocy since it craps all over deterministic/reproducible builds. ~harring