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 CC5AD138010 for ; Tue, 23 Oct 2012 21:57:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 42BDEE00B5; Tue, 23 Oct 2012 21:57:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4D651E00B5 for ; Tue, 23 Oct 2012 21:57:30 +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 549CF33D876; Tue, 23 Oct 2012 21:57:28 +0000 (UTC) Date: Tue, 23 Oct 2012 23:58:08 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-python@lists.gentoo.org Cc: python@gentoo.org Subject: [gentoo-python] Handling packages not supporting multiple Python implementations Message-ID: <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_/8jD3eWj8c7CSLSLBR=SeTVV"; protocol="application/pgp-signature" X-Archives-Salt: e874c956-479f-4f72-acf0-d1da69b5e886 X-Archives-Hash: 5c64bea3666bc6b6dcd5061b1bc6981b --Sig_/8jD3eWj8c7CSLSLBR=SeTVV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/8jD3eWj8c7CSLSLBR=SeTVV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlCHEvUACgkQfXuS5UK5QB3SAQQArnrLhu9FsQ7vDcgVDdv35A+M xSkLh9eK/w56E78npvLNlATyUyMKtNeDbjfgNeHBxauxE2O9MuND/rSHLQHAYyG6 GeFa9hqj5JlaKN0jf5+be9taJYOvLSmkVZDmdSIXRqszFCOrzhjdOumOF84O9gV4 OrUEQ1I1nKXaTZ5bU7w= =4elq -----END PGP SIGNATURE----- --Sig_/8jD3eWj8c7CSLSLBR=SeTVV--