[gentoo-python] Re: Handling packages not supporting multiple Python implementations

[Jesus Rivero (Neurogeek)]

On Thu, Oct 25, 2012 at 5:00 PM, Mike Gilbert <floppym@g.o> wrote:
> On Tue, Oct 23, 2012 at 5:58 PM, Michał Górny <mgorny@g.o> 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='^^ ( ... )'
>> 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?
>>
>
> Like you, I really can't come up with an ideal solution here.
>
> We really have 2 classes of packages here:
>
> 1. Packages that don't care what version of python you use, but
> install files outside of site-packages.
>
> 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.

I wonder if we could have a "special target" that could expand to the
current eselected python version. That way, the package not supporting
a multiple targets, could be treated the same as those who do.

Something like:

PYTHON_COMPAT=( python_current ), or something like that.

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer