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 8E70B1381F3 for ; Sun, 11 Nov 2012 23:50:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F026421C014; Sun, 11 Nov 2012 23:50:04 +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 510D421C014 for ; Sun, 11 Nov 2012 23:50:04 +0000 (UTC) Received: by mail-da0-f53.google.com with SMTP id g9so2407090dad.40 for ; Sun, 11 Nov 2012 15:50:03 -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=8qgaXfURak4NLlOetOsPpL/Pkd6WJV9jyNEQGluoLKo=; b=DeS+1ro47+bqpnKVWAzbRg+3N+BMcz/VD33MmD31GTZHKEY6yPxMnpxvVI7ku3/YlG uGjWOrZotdmA79FFku8UcIhK+FsaegGSLpw95zkI9GvJgL3fLJRveL4B68+aXy/QITNK sk2TPBjUoLiXVZ3QrpsOcBblhpXzoPR+Am7rD9XiGKylTnfjrQBXYiUIEoJom9kneqOG zy7st8pObSK+O404auropaiuOwHWSus23YvOj+YZsyUf62x1wdz5f1s856pXHRUl1m6f AcEe1/vnAUg2f9+Hdrcg/y40T9XtgiNTTJDmVInmLoOtbhNbLdF57cEsDKXIxXehRqw4 qktQ== Received: by 10.68.202.72 with SMTP id kg8mr9780885pbc.134.1352677803219; Sun, 11 Nov 2012 15:50:03 -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 ju7sm3145032pbb.60.2012.11.11.15.50.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 15:50:02 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 11 Nov 2012 15:50:03 -0800 Date: Sun, 11 Nov 2012 15:50:03 -0800 From: Brian Harring To: Mike Gilbert Cc: Micha?? G??rny , gentoo-python@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies Message-ID: <20121111235003.GB23241@localhost.corp.google.com> References: <20121110174322.656f1d67@pomiocik.lan> <20121111075248.GA23241@localhost.corp.google.com> 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: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 7d1d8126-dea3-48c8-9929-3a2f0a1b1ab5 X-Archives-Hash: fd25a9dcf48006dd684a37fd60c6a332 On Sun, Nov 11, 2012 at 01:35:20PM -0500, Mike Gilbert wrote: > On Sun, Nov 11, 2012 at 2:52 AM, Brian Harring wrote: > > 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. > > > > Following up on this and the irc conversation I eavesdropped on earlier: > > More recent versions of portage apparently filter USE_EXPAND > variables, so we can't utilize the old python abi values in USE_PYTHON > if we make that conversion. Just a note; portage's behaviour here, per the norm, is more stupid than that. EAPIs 0-4 are supposed to /not/ have that filtering, meaning portage broke it's own behaviour again. I suspect we'll retroactively change EAPIs to compensate for this, but I don't know for a fact; the discussion for that will occur at https://bugs.gentoo.org/442830 . > Converting USE_PYTHON to a use-expand would entail the following in > python.eclass: > > 1. Convert between values like "2_7-pypy-1_9" and "2.7-pypy-1.9" > The underscore version would be used for USE and IUSE and in portage > config (make.conf, profiles?). > The dot version should be used by the eclass and ebuilds and in > on-disk file names for backward compatibility. > > 2. Calculate the python abis supported by the ebuild based on > _PYTHON_GLOBALLY_SUPPORTED_ABIS and RESTRICT_PYTHON_ABIS. Add these > abis to IUSE. > This would affect all ebuilds inheriting python.eclass with > SUPPORT_PYTHON_ABIS set. > > This should not be difficult, but you never know with python.eclass. > Personally, I just assume that nobody actually wants to touch > python.eclass if it can be avoided. As stated, I'll do the work if it decreases the pains for users and eases transition (whether it be USE_PYTHON or PYTHON_TARGETS). > Also, we have dug ourselves into a small hole with PYTHON_TARGETS; > there is actually a news item out there that explains its use > (committed about the same time Brian put on the breaks), so we are > going to cause confusion if it is changed back to USE_PYTHON. I > realize this is not a reason to charge blindly forward with > PYTHON_TARGETS, but it needs to be considered. This is why I asked for the "basic legwork" that involves a roadmap/plan beyond the immediate patch. The news item has had 5 days of exposure to users. It's a bit amateur-hour to have to pull it, but if the USE_PYTHON fix-it route is ultimately less transition pain for users, we should go down that path. I *suspect* that route may not be best, although if PYTHON_TARGETS is choosen as the approach, that news item (or another) needs to be cut explicitly clarifying that everything is moving away from USE_PYTHON. Folks may view it as "an internal", but users have been using it. > I think the only benefit to keeping the USE_PYTHON name is so that > existing users don't have to learn another variable name. They would > still need to tweak their config. Either USE_PYTHON or PYTHON_TARGETS; the proposed notion of both is a recipe for pain. To be clear, any proposal that involves both existing long term is an automatic -1 from me. ~harring