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

[Mike Gilbert]

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.