From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-python+bounces-182-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 946AA138010
for <garchives@archives.gentoo.org>; Fri, 26 Oct 2012 23:55:41 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 3B43D21C00D;
Fri, 26 Oct 2012 23:55:35 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 7CF7B21C00D
for <gentoo-python@lists.gentoo.org>; Fri, 26 Oct 2012 23:55:34 +0000 (UTC)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: floppym)
by smtp.gentoo.org (Postfix) with ESMTPSA id C126F33D922
for <gentoo-python@lists.gentoo.org>; Fri, 26 Oct 2012 23:55:33 +0000 (UTC)
Received: by mail-ee0-f53.google.com with SMTP id e51so1390383eek.40
for <gentoo-python@lists.gentoo.org>; Fri, 26 Oct 2012 16:55:30 -0700 (PDT)
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
Received: by 10.14.203.65 with SMTP id e41mr37531628eeo.34.1351295730917; Fri,
26 Oct 2012 16:55:30 -0700 (PDT)
Received: by 10.223.75.137 with HTTP; Fri, 26 Oct 2012 16:55:30 -0700 (PDT)
In-Reply-To: <20121026234143.1abbd60d@pomiocik.lan>
References: <20121023235808.48cc6d9d@pomiocik.lan>
<CAJ0EP40g5osuSsW8ae0eZrtxEShUJOUkr19QDdh4yQzA4tCMHg@mail.gmail.com>
<20121026234143.1abbd60d@pomiocik.lan>
Date: Fri, 26 Oct 2012 19:55:30 -0400
Message-ID: <CAJ0EP43izvumXjJXm0dH3Y2cL0Kgoc9Us2aBw168tcy4CwK0RA@mail.gmail.com>
Subject: Re: [gentoo-python] Re: Handling packages not supporting multiple
Python implementations
From: Mike Gilbert <floppym@gentoo.org>
To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org>
Cc: gentoo-python@lists.gentoo.org, python@gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 239d30c5-4497-48bd-9bc1-de7ed6f84816
X-Archives-Hash: dfbbe9f9f79aac418fca79efe163c0d2
On Fri, Oct 26, 2012 at 5:41 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org>=
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.o=
rg> 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 to=
o
>> > 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 muc=
h
>> > 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 wa=
s
>> > 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?
>> >
>>
>> 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 well=
for #2.
>
> Indeed. The #2 will be probably handled through REQUIRED_USE, if noone
> comes up with a better idea.
>
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.