Re: [gentoo-dev] unsanctioned python 2.7 crusade

[William Hubbs]

On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote:
> 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.

Joshua and all, I am not on the python team either, but I want to drop
this link here for reference in case you haven't seen it.

https://python3statement.org

tl;dr: python 2.7 was actually deprecated in 2015 with support extended
to 2020-01-01 so folks would have time to transition off of it. All of
the upstreams on that list will be dropping support for python 2.7 this
year if they haven't already done so.

Given that, I think it is going to be extremely difficult to keep py 2.7
in the main tree.

William