1 |
On 1/12/2020 19:21, William Hubbs wrote: |
2 |
> On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote: |
3 |
>> On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote: |
4 |
>>> On 1/12/2020 17:46, David Seifert wrote: |
5 |
>>>> On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: |
6 |
>>>>> On 1/12/2020 17:32, Andreas Sturmlechner wrote: |
7 |
>>>>>> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: |
8 |
>>>>>>> It might be worthwhile to treat the removal of Python-2.7 |
9 |
>>>>>>> from |
10 |
>>>>>>> the tree in |
11 |
>>>>>>> the same manner as an EAPI deprecation and removal, given how |
12 |
>>>>>>> ingrained it |
13 |
>>>>>>> is due to its longevity. That will minimize the whiplash- |
14 |
>>>>>>> effect |
15 |
>>>>>>> of emerge |
16 |
>>>>>>> complaining about slot conflicts and dependency |
17 |
>>>>>>> conflicts. Like |
18 |
>>>>>>> I just ran |
19 |
>>>>>>> into w/ setuptools-45.0.0.0's release. |
20 |
>>>>>> |
21 |
>>>>>> So, no packaging of >=setuptools-45.0.0 until the end of 2020? |
22 |
>>>>>> Do |
23 |
>>>>>> you want to |
24 |
>>>>>> freeze all python libs that upstreams are dropping py27 support |
25 |
>>>>>> from? |
26 |
>>>>>> |
27 |
>>>>> |
28 |
>>>>> Not saying not to package it. Right now, the issue seems to be |
29 |
>>>>> it |
30 |
>>>>> causes |
31 |
>>>>> dependency conflicts in emerge's depgraph parsing when |
32 |
>>>>> PYTHON_TARGETS |
33 |
>>>>> includes python2_7 support. Remove that and stick with python3_* |
34 |
>>>>> only, then |
35 |
>>>>> other packages that need python2_7 will whine. |
36 |
>>>>> |
37 |
>>>>> Did setuptools-45.0.0 remove all python2 support? I looked at |
38 |
>>>>> the |
39 |
>>>>> commit |
40 |
>>>>> log, and it's only the title that any meaningful hint that it may |
41 |
>>>>> have, |
42 |
>>>>> "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, |
43 |
>>>>> then |
44 |
>>>>> that |
45 |
>>>>> change is the right change, but anyone with a userland that has a |
46 |
>>>>> mix |
47 |
>>>>> of |
48 |
>>>>> python2 and python3 is going to have difficulty getting that |
49 |
>>>>> update |
50 |
>>>>> to merge |
51 |
>>>>> in, so I really can't go higher than setuptools-44.0.0 for the |
52 |
>>>>> time |
53 |
>>>>> being. |
54 |
>>>>> |
55 |
>>>> |
56 |
>>>> https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 |
57 |
>>> |
58 |
>>> At least you didn't squirrel that behind a lmgtfy link </smirk> |
59 |
>>> |
60 |
>>> In any event, it's clear the tree does not seem set up real well to |
61 |
>>> handle |
62 |
>>> the random removal or deprecation of python2 support. And |
63 |
>>> considering |
64 |
>>> python2.7 isn't dead //yet//, I have to question the wisdom of |
65 |
>>> removing |
66 |
>>> packages that still support 2.7, and also wonder if there's a way to |
67 |
>>> be more |
68 |
>>> graceful in handling updates to packages whose upstream decides to |
69 |
>>> remove |
70 |
>>> python2 support. |
71 |
>>> |
72 |
>>> Or we can just continue down the current Mad Max methodology and |
73 |
>>> leave it to |
74 |
>>> every developer for themselves. |
75 |
>>> |
76 |
>> |
77 |
>> Or - you know - you could help? Talk is cheap, gracefully removing py2 |
78 |
>> from the tree is the hard part. A quick grep tells me we have 4388 |
79 |
>> ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun |
80 |
>> devising a plan (and then doing the actual work). Pro-tip: "Don't |
81 |
>> remove py2" is not an actual plan when many important core dependencies |
82 |
>> have started removing py2 already. |
83 |
> |
84 |
> Joshua and all, I am not on the python team either, but I want to drop |
85 |
> this link here for reference in case you haven't seen it. |
86 |
> |
87 |
> https://python3statement.org |
88 |
> |
89 |
> tl;dr: python 2.7 was actually deprecated in 2015 with support extended |
90 |
> to 2020-01-01 so folks would have time to transition off of it. All of |
91 |
> the upstreams on that list will be dropping support for python 2.7 this |
92 |
> year if they haven't already done so. |
93 |
> |
94 |
> Given that, I think it is going to be extremely difficult to keep py 2.7 |
95 |
> in the main tree. |
96 |
> |
97 |
> William |
98 |
|
99 |
That as it may be, I'm generally of the opinion that as long as there are |
100 |
still new releases, we should support it. Once the upstream releases stop, |
101 |
then remove it. For a normal package, this would be a complete non-issue, |
102 |
but Python is hardly a normal package. That said, if we don't have the |
103 |
manpower or the desire to maintain it, then I don't see a problem with |
104 |
removing it. |
105 |
|
106 |
I just wish emerge was better at handling the resulting slot/dependency |
107 |
conflicts that are arising as some packages get pulled and others updated |
108 |
with py3-only support. I am working now to remove the remaining py2 |
109 |
packages from my systems and then rebuild the python packages to only handle |
110 |
py3. The MIPS box is going to take its sweet time on that, though, but cest |
111 |
la vie... |
112 |
|
113 |
-- |
114 |
Joshua Kinard |
115 |
Gentoo/MIPS |
116 |
kumba@g.o |
117 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
118 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
119 |
|
120 |
"The past tempts us, the present confuses us, the future frightens us. And |
121 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
122 |
|
123 |
--Emperor Turhan, Centauri Republic |