| 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 |
Archives