Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

[Patrick McLean]

On Thu, 26 Mar 2020 21:11:11 +0100
Michał Górny <mgorny@g.o> wrote:

> On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > There are situations in which downstream overlays need to have versions
> > of python which Gentoo no longer supports in the tree.
> >
> > Currently, the only way to do this is for the overlay author to fork
> > python-utils-r1.eclass. This is highly undesirable since it creates a
> > very significant maintenance burden for the overlay author.
>
> Is it preferable to create the maintenance burden on Gentoo developers
> instead?  Is it fair that paid company developers shift the burden
> on people who work on Gentoo in their free time, and already have their
> plate full?

We have no intention of shifting maintenance burdens anywhere, we want
to make minor changes to make it easier for us to keep up. It's the
same as a Gentoo developer asking an upstream project to make minor
changes to their build system to support DESTDIR or a sandbox fix.

>
> > The simplest way would be to apply the following patch.
> > In this situation, all the overlay author
> > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.
>
> ...which solves exactly zero problems because the eclass still doesn't
> support the implementation in question.  The best it could do is sweep
> part of the problem under the carpet.

We don't care if it *actually* supports it, the ebuilds in question
aren't going to be installed on modern machines. We just want it to not
blow up in the global scope.

> Even if it miraculously works right now at all, it will probably fail or
> misbehave randomly.  Any eclass change might break it.  Then one cheap
> hack will serve as an excuse to add one more, and another.\
>
> > The other option would be to move _PYTHON_ALL_IMPLS and  the
> > implementation of _python_impl_supported to a separate eclass, e.g.
> > python-impls-r1.eclass. This eclass could be forked freely downstream
> > without worrying about the other python eclasses.
>
> Again, this doesn't solve the problem.  It just moves the problem
> elsewhere.
>

How does this not solve the problem? Overlays could trivially support
different implementations, without maintaining a lot of forks. We are
quite happy to do the work to split it out to a separate eclass.

> > Thoughts?
>
> I've already told you that if you want to fork, fork all eclasses.  Then
> you wouldn't have to worry about internal API going out of sync.
>
> Or don't autoupdate ::gentoo when eclasses change.
>