Gentoo Archives: gentoo-dev

From: Joshua Kinard <kumba@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python
Date: Mon, 22 Feb 2021 01:32:50
Message-Id: f3b35ead-dbcf-d2fd-a676-8d16dd6196ea@gentoo.org
In Reply to: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python by "Michał Górny"
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

Replies