Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Mike Gilbert <floppym@gentoo.org>]

On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2019-12-06 16:48, Mike Gilbert wrote:
> > It's not quite so simple as you make it sound. There really isn't a
> > viable way to defer removal of python2-only packages until we remove
> > dev-lang/python:2.7.
> >
> > An increasing number of python packages are dropping support for
> > python2 when upstream releases new versions. When this happens, we
> > really need to drop python2 support from all reverse dependencies as
> > well. Alternative strategies like slotting or compatibility packages
> > are a stopgap at best, and become a problem as soon as bugs are
> > reported or security issues pop up.
> >
> > Ripping out python2 support for all reverse dependencies of a core
> > package is rather daunting, and is likely to cause much more of an
> > uproar than the recent mask. Aaron is really tackling the low-hanging
> > fruit at this point: leaves on the depgraph.
>
> But what's the problem here? Why do you need to rip out Py2 support? PHP
> project is facing a similar situation with PHP 5.6, 7.0 and now 7.1
> becoming EOL. Sure, there are way more Python packages but could you
> explain why you can't do the same like we did? I.e. new versions of PHP
> PECL extension also dropped support for PHP versions which are EOL. When
> we bump these packages we just drop PHP versions which are no longer
> able to run these extensions. But we keep at least last version still
> supporting PHP version which is/become EOL until we finally get rid of
> this PHP version as a whole. For example, a lot of packages are now
> masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of
> PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users
> by starting to remove PECL extension for this version while
> dev-lang/php:5.6 was still a thing...

That's going to cause a very confusing user-experience due to
conflicting PYTHON_TARGETS values on the various packages. It's also
going to cause users to have old/unsupported/buggy versions of various
random python packages depending on what set of reverse dependencies
they happen to have installed.

For example, lets say the next release of dev-python/example drops
support for python2, and also adds some new features and fixes some
bugs.

If the user has python2_7 enabled for any reverse dependency of
dev-python/example, Portage will be forced to do one of two things:

1. Keep the old version installed.
2. Emit a confusing error message to the user since the use-dependency
on dev-python/example[python_targets_python2_7] cannot be resolved
with the latest visible version.

Option 1 is bad because the user will be missing out on bug fixes and
new features. Option 2 will probably generate some bug reports that we
will have to close as CANTFIX.

It's also a giant pain in the butt for python maintainers since it
makes cleaning up old versions very error-prone. This may also be a
problem if the security team demands we remove it.