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

[Alec Warner]

On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean <chutzpah@g.o> wrote:

> 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.
>

Couldn't you simply remove the ebuilds from the overlay entirely in this
case? It's my understanding that on the machines with the packages
installed, the merged package metadata is being used (which is why those
machines work) and since the newer machines don't have this merged package
metadata, they don't work properly.

-A


>
> 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.
>
>