1 |
On 1/12/2020 17:46, David Seifert wrote: |
2 |
> On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: |
3 |
>> On 1/12/2020 17:32, Andreas Sturmlechner wrote: |
4 |
>>> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: |
5 |
>>>> It might be worthwhile to treat the removal of Python-2.7 from |
6 |
>>>> the tree in |
7 |
>>>> the same manner as an EAPI deprecation and removal, given how |
8 |
>>>> ingrained it |
9 |
>>>> is due to its longevity. That will minimize the whiplash-effect |
10 |
>>>> of emerge |
11 |
>>>> complaining about slot conflicts and dependency conflicts. Like |
12 |
>>>> I just ran |
13 |
>>>> into w/ setuptools-45.0.0.0's release. |
14 |
>>> |
15 |
>>> So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do |
16 |
>>> you want to |
17 |
>>> freeze all python libs that upstreams are dropping py27 support |
18 |
>>> from? |
19 |
>>> |
20 |
>> |
21 |
>> Not saying not to package it. Right now, the issue seems to be it |
22 |
>> causes |
23 |
>> dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS |
24 |
>> includes python2_7 support. Remove that and stick with python3_* |
25 |
>> only, then |
26 |
>> other packages that need python2_7 will whine. |
27 |
>> |
28 |
>> Did setuptools-45.0.0 remove all python2 support? I looked at the |
29 |
>> commit |
30 |
>> log, and it's only the title that any meaningful hint that it may |
31 |
>> have, |
32 |
>> "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, then |
33 |
>> that |
34 |
>> change is the right change, but anyone with a userland that has a mix |
35 |
>> of |
36 |
>> python2 and python3 is going to have difficulty getting that update |
37 |
>> to merge |
38 |
>> in, so I really can't go higher than setuptools-44.0.0 for the time |
39 |
>> being. |
40 |
>> |
41 |
> |
42 |
> https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 |
43 |
|
44 |
At least you didn't squirrel that behind a lmgtfy link </smirk> |
45 |
|
46 |
In any event, it's clear the tree does not seem set up real well to handle |
47 |
the random removal or deprecation of python2 support. And considering |
48 |
python2.7 isn't dead //yet//, I have to question the wisdom of removing |
49 |
packages that still support 2.7, and also wonder if there's a way to be more |
50 |
graceful in handling updates to packages whose upstream decides to remove |
51 |
python2 support. |
52 |
|
53 |
Or we can just continue down the current Mad Max methodology and leave it to |
54 |
every developer for themselves. |
55 |
|
56 |
-- |
57 |
Joshua Kinard |
58 |
Gentoo/MIPS |
59 |
kumba@g.o |
60 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
61 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
62 |
|
63 |
"The past tempts us, the present confuses us, the future frightens us. And |
64 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
65 |
|
66 |
--Emperor Turhan, Centauri Republic |