Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

[Patrick McLean]

On Fri, 27 Mar 2020 14:48:53 -0700
Matt Turner <mattst88@g.o> wrote:

> On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean <chutzpah@g.o> wrote:
> >
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.
>
> (I think the issue is that you have some packages that still need
> Python 3.4. Correct me if I'm wrong)
>
> How many packages do you need to work with Python 3.4? Presumably just
> a couple and then a pile of dependencies in ::gentoo?
>

For our particular purpose, it's more complicated than that. We do not
expect or want ::gentoo to try support Python 3.4 in any way. We have an
overlay that is shared on a lot of machines, some of those machines are
older than others. As such we still have ebuilds that only support
python3_4 that still exist in the overlay. We would like it if the
existence of these packages in the overlay, do not cause metadata
generation or dependency calculation to explode on the more up-to-date
machines.

We do not need Python 3.4 packages to be installable on the newer
machines, we just need them not to explode.

I am trying to come up with a solution that *any* overlay can use, I
am happy to do work towards that end. Basically, it would be very
nice if there was a minimal eclass that handles all the python 
version compatibility. Almost everything in the eclasses does not care
about versions.

This is not meant to be something just for our usage, we want this to
be usable for *any* overlay, and are more than happy to make things as
generic as possible. If some overlay wants to support Python 3.10 alpha,
resurrect jython support, or add Ironpython support, without forking
all the eclasses, I would like to think that could be doable as well.