1 |
On 2/21/2021 08:01, Michał Górny wrote: |
2 |
> Hi, |
3 |
> |
4 |
> FYI, a few member of Python upstream are continuing their crusade |
5 |
> against minor architectures not supported by Rust. This time, they're |
6 |
> discussing actively removing support for platforms they don't officially |
7 |
> support, and requiring people to maintain external patches forever. |
8 |
|
9 |
In case I missed something, what is the intersection here between Rust and |
10 |
Python? Is it just the Python devs taking a page out of Rust's guidebook on |
11 |
platform/arch support, or is there some change coming down the road, like |
12 |
where Python will be re-written in Rust? |
13 |
|
14 |
|
15 |
> -------- Forwarded Message -------- |
16 |
> From: Victor Stinner <vstinner@××××××.org> |
17 |
> To: Python Dev <Python-Dev@××××××.org> |
18 |
> Subject: [Python-Dev] Move support of legacy platforms/architectures |
19 |
> outside Python |
20 |
> Date: Sun, 21 Feb 2021 13:13:45 +0100 |
21 |
> |
22 |
>> Hi, |
23 |
>> |
24 |
>> I propose to actively remove support for *legacy* platforms and |
25 |
>> architectures which are not supported by Python according to PEP 11 |
26 |
>> rules: hardware no longer sold and end-of-life operating systems. The |
27 |
>> removal should be discussed on a case by case basis, but I would like |
28 |
>> to get an agreement on the overall idea first. Hobbyists wanting to |
29 |
>> support these platforms/archs can continue to support them with |
30 |
>> patches maintained outside Python. For example, I consider that the |
31 |
>> 16-bit m68k architecture is legacy, whereas the OpenBSD platform is |
32 |
>> still actively maintained. |
33 |
>> |
34 |
>> I already know that there will be a strike back: "oh no, you must |
35 |
>> continue to support my architecture" and "their existing code should |
36 |
>> stay and doesn't cost anything to maintain". Python is maintained by |
37 |
>> volunteers, the majority is contributing in their free time, so people |
38 |
>> are free to use their free time as they want. You cannot ask core |
39 |
>> developers to support your favorite *legacy* platform/architecture if |
40 |
>> they don't want to. |
41 |
>> |
42 |
>> In short, I propose to move maintenance of the legacy platforms/archs |
43 |
>> outside Python: people are free to continue support them as patches. |
44 |
>> |
45 |
>> -- |
46 |
>> |
47 |
>> Concrete example: Christian Heimes proposed to drop support for 31-bit |
48 |
>> s390 Linux: |
49 |
>> https://bugs.python.org/issue43179 |
50 |
>> |
51 |
>> The lack of clear definition on how a platform is supported or not |
52 |
>> confuses users who consider that their favorite platform/arch is |
53 |
>> supported, whereas core developers don't want to support it since it |
54 |
>> would be too much work. |
55 |
>> |
56 |
>> In fact, the PEP 11 has clear and explicit rules: |
57 |
>> https://www.python.org/dev/peps/pep-0011/#supporting-platforms |
58 |
>> |
59 |
>> A platform is only considered as supported if the following two |
60 |
>> conditions are met: |
61 |
>> |
62 |
>> 1) a core developer needs to volunteer to maintain platform-specific code |
63 |
>> 2) a stable buildbot must be provided |
64 |
>> |
65 |
>> Last October, I proposed to drop Solaris support (bpo-42173). Jakub |
66 |
>> Kulik stepped in and proposed some Solaris patches, so I abandoned my |
67 |
>> idea. But I still don't see any running Solaris buildbot worker, and |
68 |
>> there is still no core developer volunteer to maintain Solaris |
69 |
>> support. It's unclear to me if Python has "best effort" support for |
70 |
>> Solaris, of if Solaris is "not supported". |
71 |
|
72 |
Just commentary here, but likely they'll need to go and poke Oracle for |
73 |
proper Solaris support. I wonder, though, whether the illumos community |
74 |
could keep this alive, unless illumos has drifted too far apart from Solaris |
75 |
11.4 and becomes its own build tuple? |
76 |
|
77 |
|
78 |
>> -- |
79 |
>> |
80 |
>> Over the years, Python was ported to tons of platforms and CPU |
81 |
>> architectures. It didn't matter if the platform or the architecture |
82 |
>> was commonly used or not. 30 years later, Python still has the code |
83 |
>> for many legacy platforms and architectures. Some hardware is no |
84 |
>> longer sold but kept alive by hobbyists, especially members of retro |
85 |
>> computing groups. |
86 |
|
87 |
:: glances around nervously and hides in a bush w/ his old SGI machines :: |
88 |
|
89 |
|
90 |
>> Some Linux distributions like Gentoo and Debian are trying to support |
91 |
>> most architectures which are supported by these hobbyist groups, |
92 |
>> whereas some other distributions like Ubuntu are limited to a few |
93 |
>> platforms. For example, Ubuntu 20.4.2 LTS server supports 4 |
94 |
>> architectures: x86-64, AArch64 (ARM), POWER and s390x. I guess that |
95 |
>> the difference between Debian and Ubuntu is that Ubuntu is a Canonical |
96 |
>> product, Canonical sells professional support and so cannot support |
97 |
>> too many architectures. Each architecture support requires to build |
98 |
>> all packages on it, tests the packages, have experts who fix issues |
99 |
>> specific to this arch, etc. |
100 |
>> |
101 |
>> -- |
102 |
>> |
103 |
>> Python has different kinds of platform and architecture supports. In |
104 |
>> practice, I would say that we have: |
105 |
>> |
106 |
>> * (1) Fully supported. Platform/architecture used by core developers |
107 |
>> and have at least one working buildbot worker: fully supported. Since |
108 |
>> core developers want to use Python on their machine, they fix issues |
109 |
>> as soon as they notice them. Examples: x86-64 on Linux, Windows and |
110 |
>> macOS. |
111 |
>> |
112 |
>> * (2) Best effort. Platform/architecture which has a buildbot worker |
113 |
>> usually not used by core developers. Regressions (buildbot failures) |
114 |
>> are reported to bugs.python.org, if someone investigates and provides |
115 |
>> a fix, the fix is merged. But there is usually no "proactive" work to |
116 |
>> ensure that Python works "perfectly" on these platforms. Example: |
117 |
>> FreeBSD/x86-64. |
118 |
|
119 |
Someone from Python should probably look up the port maintainer on FreeBSD |
120 |
here and poke them about this. FreeBSD/x86_64 is a Tier 1 architecture, so |
121 |
it gets attention. Likely the port maintainer just hasn't fed any support |
122 |
patches back upstream. |
123 |
|
124 |
|
125 |
>> * (3) Not (officially) supported. We enter the blurry grey area. There |
126 |
>> is no buildbot worker, no core dev use it, but Python contains code |
127 |
>> specific to these platforms/architectures. Example: 16-bit m68k and |
128 |
>> 31-bit s390 architectures, OpenBSD. |
129 |
>> |
130 |
>> The Rust programming language has 3 categories of Platform Support, |
131 |
>> the last one is : |
132 |
>> |
133 |
>> "Tier 3 platforms are those which the Rust codebase has support for, |
134 |
>> but which are not built or tested automatically, and may not work. |
135 |
>> Official builds are not available." |
136 |
>> https://doc.rust-lang.org/nightly/rustc/platform-support.html |
137 |
>> |
138 |
>> Rust Tier 3 looks like our "Not supported" category. |
139 |
>> |
140 |
>> Maybe we should have a better definition in the PEP 11 of our 3 support levels. |
141 |
>> |
142 |
>> There is also a 4th category: platforms/archs which are really not |
143 |
>> supported, like they legacy ones for which we removed the code :-) |
144 |
>> Examples: BeOS, MacOS 9, platforms with no thread support, etc. |
145 |
|
146 |
For BeOS, probably a question for the Haiku community on what, if any, |
147 |
patches they are maintaining to support Python there. IMHO, BeOS support |
148 |
can probably be dropped and replaced with support for Haiku. That project |
149 |
is coming along rather nicely. |
150 |
|
151 |
|
152 |
>> |
153 |
>> -- |
154 |
>> |
155 |
>> There is also a "Stable Buildbot" category used by the "Release |
156 |
>> Status" web page: |
157 |
>> https://buildbot.python.org/all/#/release_status |
158 |
>> |
159 |
>> There is no clear rule why is a worker is added to that list or not. |
160 |
>> For example, there are two FreeBSD workers which runs FreeBSD CURRENT: |
161 |
>> the FreeBSD development branch. I don't think that it should be |
162 |
>> declared as "stable". |
163 |
>> |
164 |
>> Victor |
165 |
>> -- |
166 |
>> Night gathers, and now my watch begins. It shall not end until my death. |
167 |
>> _______________________________________________ |
168 |
>> Python-Dev mailing list -- python-dev@××××××.org |
169 |
>> To unsubscribe send an email to python-dev-leave@××××××.org |
170 |
>> https://mail.python.org/mailman3/lists/python-dev.python.org/ |
171 |
>> Message archived at https://mail.python.org/archives/list/python-dev@××××××.org/message/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/ |
172 |
>> Code of Conduct: http://python.org/psf/codeofconduct/ |
173 |
> |
174 |
|
175 |
|
176 |
-- |
177 |
Joshua Kinard |
178 |
Gentoo/MIPS |
179 |
kumba@g.o |
180 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
181 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
182 |
|
183 |
"The past tempts us, the present confuses us, the future frightens us. And |
184 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
185 |
|
186 |
--Emperor Turhan, Centauri Republic |