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 E8E48138010 for ; Fri, 26 Oct 2012 21:41:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 549DFE05F1; Fri, 26 Oct 2012 21:40:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 59FB7E05F1 for ; Fri, 26 Oct 2012 21:40:58 +0000 (UTC) Received: from pomiocik.lan (77-255-14-203.adsl.inetia.pl [77.255.14.203]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 359A833D803; Fri, 26 Oct 2012 21:40:55 +0000 (UTC) Date: Fri, 26 Oct 2012 23:41:43 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Mike Gilbert Cc: gentoo-python@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-python] Re: Handling packages not supporting multiple Python implementations Message-ID: <20121026234143.1abbd60d@pomiocik.lan> In-Reply-To: References: <20121023235808.48cc6d9d@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/bK7oyxKDGd6MAc2g.ASNkOK"; protocol="application/pgp-signature" X-Archives-Salt: 1dfdd15c-cb69-4c52-91bb-6e8374507425 X-Archives-Hash: 8754a57a6eb764202d12753b5eefbb6a --Sig_/bK7oyxKDGd6MAc2g.ASNkOK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 25 Oct 2012 17:00:22 -0400 Mike Gilbert wrote: > On Tue, Oct 23, 2012 at 5:58 PM, Micha=C5=82 G=C3=B3rny wrote: > > Hello, > > > > After starting to deploy python-r1 on packages supporting multiple > > Python implementations, I believe it is time to start thinking about > > those packages which don't support that. Firstly, I would like to gain > > a general feedback/ideas on the possible solutions, without getting too > > deep into the technical details of it. > > > > As far as I can think, we have the following possibilities: > > > > > > 1) Assume that installing stuff for a single Python implementation is > > deprecated and let the packages rot with the old eclass. > > > > It is probably the simplest solution (i.e. not doing anything to > > address the issue) but truth be told, I doubt this will actually work. > > People will just keep using the old eclass which doesn't really do much > > good for those packages... > > > > And even if some people will actually start supporting multiple > > implementations... that may be even worse. Just look at dev-libs/boost > > to see what I mean. > > > > > > 2) Use a xor-type REQUIRED_USE for those packages. > > > > Put the whole set of PYTHON_TARGETS but add a REQUIRED_USE=3D'^^ ( ... = )' > > for them, effectively requesting only a single implementation being > > enabled. > > > > I believe that this is quite a good solution, at least from > > the dependency point of view. We clearly express which Python > > implementations are supported by a particular package and which one was > > enabled. We can express cross-package dependencies cleanly. > > > > The problem lies in user-friendliness. Although with the current > > default (python2_7 only) it wouldn't cause any trouble, whenever user > > enables more than a single implementation, every single-implementation > > package will require package.use adjustment. This will become an even > > more widespread issue when we decide to re-enable Python 3. > > > > To be honest, I don't see any good way around that. > > > > > > 3) Use implicit implementation selection (like python.eclass). > > > > Well, as some say, this is a very good solution since it's well tested. > > Its limitations and brokenness are obvious. Just I doubt it is really > > worth the effort to write something that bad. > > > > The main problem here is that the chosen Python implementation is > > implicit. Binary packages don't express it. Cross-package dependencies > > don't express it. User changes the implementation, stuff breaks > > silently and you end up with some kind of python-updater (why a tool > > to fix breakage is called 'updater'?!). > > > > > > Do you have any more ideas? Opinions? > > >=20 > Like you, I really can't come up with an ideal solution here. >=20 > We really have 2 classes of packages here: Thanks for pointing that out. > 1. Packages that don't care what version of python you use, but > install files outside of site-packages. That sounds a bit like a custom case to me. Not sure if python-r1 should support those out-of-the-box or just provide a few utility functions (python-utils-r1?) to help installing them. > 2. Packages that build code (like libraries) against a specific > version of python/libpython. >=20 > The implicit implementation selection works fine for #1, but not so well = for #2. Indeed. The #2 will be probably handled through REQUIRED_USE, if noone comes up with a better idea. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/bK7oyxKDGd6MAc2g.ASNkOK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlCLA5cACgkQfXuS5UK5QB3AAgP/RhqUt6BL3Jc0oBvdOtZ6RQkO hsLWJFKVIN9v6TygOM2dcVRGyTzRrN5zjCycEwD+KIfdxxu67B8a5MPi1XkedUzv d8dBKVdQWHDOIYjyqyqg1VLJv8KeTH7Z8rDqefaRKXlLwYYkbDiyqgMTIZKggIU5 /i1Z2yoe/tLeGihk1HA= =a0p6 -----END PGP SIGNATURE----- --Sig_/bK7oyxKDGd6MAc2g.ASNkOK--