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

[Patrick McLean]

On Fri, 27 Mar 2020 15:51:35 -0700
Alec Warner <antarus@g.o> wrote:

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

Sometimes we have to fix the older machines, so we have to keep
everything around until none of our machines are using it any more.

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