From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-python+bounces-185-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 3260F138010 for <garchives@archives.gentoo.org>; Sat, 27 Oct 2012 07:29:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C71921C010; Sat, 27 Oct 2012 07:29:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7E05B21C010 for <gentoo-python@lists.gentoo.org>; Sat, 27 Oct 2012 07:29:39 +0000 (UTC) Received: from pomiocik.lan (77-255-21-244.adsl.inetia.pl [77.255.21.244]) (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 B5A5633D922; Sat, 27 Oct 2012 07:29:37 +0000 (UTC) Date: Sat, 27 Oct 2012 09:30:19 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org> To: Mike Gilbert <floppym@gentoo.org> Cc: gentoo-python@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-python] Re: Handling packages not supporting multiple Python implementations Message-ID: <20121027093019.50a3aa00@pomiocik.lan> In-Reply-To: <CAJ0EP43izvumXjJXm0dH3Y2cL0Kgoc9Us2aBw168tcy4CwK0RA@mail.gmail.com> References: <20121023235808.48cc6d9d@pomiocik.lan> <CAJ0EP40g5osuSsW8ae0eZrtxEShUJOUkr19QDdh4yQzA4tCMHg@mail.gmail.com> <20121026234143.1abbd60d@pomiocik.lan> <CAJ0EP43izvumXjJXm0dH3Y2cL0Kgoc9Us2aBw168tcy4CwK0RA@mail.gmail.com> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/0Eak1Jwko+qQ/Fipt+k2AAE"; protocol="application/pgp-signature" X-Archives-Salt: 47ba3a8c-6924-4d68-97db-390b4875f4de X-Archives-Hash: 923e003fbf8e95b63cffd731253597a2 --Sig_/0Eak1Jwko+qQ/Fipt+k2AAE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 26 Oct 2012 19:55:30 -0400 Mike Gilbert <floppym@gentoo.org> wrote: > On Fri, Oct 26, 2012 at 5:41 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.or= g> wrote: > > On Thu, 25 Oct 2012 17:00:22 -0400 > > Mike Gilbert <floppym@gentoo.org> wrote: > > > >> On Tue, Oct 23, 2012 at 5:58 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo= .org> 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 ga= in > >> > 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 wor= k. > >> > People will just keep using the old eclass which doesn't really do m= uch > >> > 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/boo= st > >> > 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-implementati= on > >> > 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 test= ed. > >> > 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 dependenci= es > >> > 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? > >> > > >> > >> Like you, I really can't come up with an ideal solution here. > >> > >> 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. > >> > >> The implicit implementation selection works fine for #1, but not so we= ll for #2. > > > > Indeed. The #2 will be probably handled through REQUIRED_USE, if noone > > comes up with a better idea. > > >=20 > Yeah, I probably need to remove python3_2 from arch/*/make.defaults > before we move forward with that plan. I'm sure that will make a few > people feel better anyway. Hmm, so we still have that somewhere? I thought folks forced us to remove it completely. Probably p-d-ng wasn't spread enough for them to notice ;). --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/0Eak1Jwko+qQ/Fipt+k2AAE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlCLjY8ACgkQfXuS5UK5QB1rCwQAhSPArs5R4OTO3Dqj4B0avI8T 4t4WsX4DyHJI52tXhES9xIjBGT2B4jJZ/Q6qOgwOzfIEYhbY3yiplqCz8M/RQ3yl bl1u3zrBzLtq2tzaSYjhlyzgDvDbAewq9sadFtH/mJd98gc79EHORhGu3OKA61o7 mMuxX8vv9DaW7SO8JTY= =N/s5 -----END PGP SIGNATURE----- --Sig_/0Eak1Jwko+qQ/Fipt+k2AAE--