On Fri, 27 Mar 2020 15:51:35 -0700 Alec Warner <anta...@gentoo.org> wrote:
> On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean <chutz...@gentoo.org> wrote: > > > On Fri, 27 Mar 2020 14:48:53 -0700 > > Matt Turner <matts...@gentoo.org> wrote: > > > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean <chutz...@gentoo.org> > > 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. > > > >
