| 1 |
On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote: |
| 2 |
> On 1/12/2020 17:46, David Seifert wrote: |
| 3 |
> > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: |
| 4 |
> > > On 1/12/2020 17:32, Andreas Sturmlechner wrote: |
| 5 |
> > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: |
| 6 |
> > > > > It might be worthwhile to treat the removal of Python-2.7 |
| 7 |
> > > > > from |
| 8 |
> > > > > the tree in |
| 9 |
> > > > > the same manner as an EAPI deprecation and removal, given how |
| 10 |
> > > > > ingrained it |
| 11 |
> > > > > is due to its longevity. That will minimize the whiplash- |
| 12 |
> > > > > effect |
| 13 |
> > > > > of emerge |
| 14 |
> > > > > complaining about slot conflicts and dependency |
| 15 |
> > > > > conflicts. Like |
| 16 |
> > > > > I just ran |
| 17 |
> > > > > into w/ setuptools-45.0.0.0's release. |
| 18 |
> > > > |
| 19 |
> > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020? |
| 20 |
> > > > Do |
| 21 |
> > > > you want to |
| 22 |
> > > > freeze all python libs that upstreams are dropping py27 support |
| 23 |
> > > > from? |
| 24 |
> > > > |
| 25 |
> > > |
| 26 |
> > > Not saying not to package it. Right now, the issue seems to be |
| 27 |
> > > it |
| 28 |
> > > causes |
| 29 |
> > > dependency conflicts in emerge's depgraph parsing when |
| 30 |
> > > PYTHON_TARGETS |
| 31 |
> > > includes python2_7 support. Remove that and stick with python3_* |
| 32 |
> > > only, then |
| 33 |
> > > other packages that need python2_7 will whine. |
| 34 |
> > > |
| 35 |
> > > Did setuptools-45.0.0 remove all python2 support? I looked at |
| 36 |
> > > the |
| 37 |
> > > commit |
| 38 |
> > > log, and it's only the title that any meaningful hint that it may |
| 39 |
> > > have, |
| 40 |
> > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, |
| 41 |
> > > then |
| 42 |
> > > that |
| 43 |
> > > change is the right change, but anyone with a userland that has a |
| 44 |
> > > mix |
| 45 |
> > > of |
| 46 |
> > > python2 and python3 is going to have difficulty getting that |
| 47 |
> > > update |
| 48 |
> > > to merge |
| 49 |
> > > in, so I really can't go higher than setuptools-44.0.0 for the |
| 50 |
> > > time |
| 51 |
> > > being. |
| 52 |
> > > |
| 53 |
> > |
| 54 |
> > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 |
| 55 |
> |
| 56 |
> At least you didn't squirrel that behind a lmgtfy link </smirk> |
| 57 |
> |
| 58 |
> In any event, it's clear the tree does not seem set up real well to |
| 59 |
> handle |
| 60 |
> the random removal or deprecation of python2 support. And |
| 61 |
> considering |
| 62 |
> python2.7 isn't dead //yet//, I have to question the wisdom of |
| 63 |
> removing |
| 64 |
> packages that still support 2.7, and also wonder if there's a way to |
| 65 |
> be more |
| 66 |
> graceful in handling updates to packages whose upstream decides to |
| 67 |
> remove |
| 68 |
> python2 support. |
| 69 |
> |
| 70 |
> Or we can just continue down the current Mad Max methodology and |
| 71 |
> leave it to |
| 72 |
> every developer for themselves. |
| 73 |
> |
| 74 |
|
| 75 |
Or - you know - you could help? Talk is cheap, gracefully removing py2 |
| 76 |
from the tree is the hard part. A quick grep tells me we have 4388 |
| 77 |
ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun |
| 78 |
devising a plan (and then doing the actual work). Pro-tip: "Don't |
| 79 |
remove py2" is not an actual plan when many important core dependencies |
| 80 |
have started removing py2 already. |
Archives