Re: [gentoo-dev] unsanctioned python 2.7 crusade

[David Seifert <soap@gentoo.org>]

On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote:
> On 1/12/2020 17:46, David Seifert wrote:
> > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
> > > On 1/12/2020 17:32, Andreas Sturmlechner wrote:
> > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
> > > > > It might be worthwhile to treat the removal of Python-2.7
> > > > > from
> > > > > the tree in
> > > > > the same manner as an EAPI deprecation and removal, given how
> > > > > ingrained it
> > > > > is due to its longevity.  That will minimize the whiplash-
> > > > > effect
> > > > > of emerge
> > > > > complaining about slot conflicts and dependency
> > > > > conflicts.  Like
> > > > > I just ran
> > > > > into w/ setuptools-45.0.0.0's release.
> > > > 
> > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020?
> > > > Do
> > > > you want to 
> > > > freeze all python libs that upstreams are dropping py27 support
> > > > from?
> > > > 
> > > 
> > > Not saying not to package it.  Right now, the issue seems to be
> > > it
> > > causes
> > > dependency conflicts in emerge's depgraph parsing when
> > > PYTHON_TARGETS
> > > includes python2_7 support.  Remove that and stick with python3_*
> > > only, then
> > > other packages that need python2_7 will whine.
> > > 
> > > Did setuptools-45.0.0 remove all python2 support?  I looked at
> > > the
> > > commit
> > > log, and it's only the title that any meaningful hint that it may
> > > have,
> > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did,
> > > then
> > > that
> > > change is the right change, but anyone with a userland that has a
> > > mix
> > > of
> > > python2 and python3 is going to have difficulty getting that
> > > update
> > > to merge
> > > in, so I really can't go higher than setuptools-44.0.0 for the
> > > time
> > > being.
> > > 
> > 
> > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0
> 
> At least you didn't squirrel that behind a lmgtfy link </smirk>
> 
> In any event, it's clear the tree does not seem set up real well to
> handle
> the random removal or deprecation of python2 support.  And
> considering
> python2.7 isn't dead //yet//, I have to question the wisdom of
> removing
> packages that still support 2.7, and also wonder if there's a way to
> be more
> graceful in handling updates to packages whose upstream decides to
> remove
> python2 support.
> 
> Or we can just continue down the current Mad Max methodology and
> leave it to
> every developer for themselves.
> 

Or - you know - you could help? Talk is cheap, gracefully removing py2
from the tree is the hard part. A quick grep tells me we have 4388
ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun
devising a plan (and then doing the actual work). Pro-tip: "Don't
remove py2" is not an actual plan when many important core dependencies
have started removing py2 already.