When a platform loses Tier support status as defined in PEP-11 : Unsupporting platforms, the current text is rather draconian. It claims we must break the build and configure for said platform.
This seems unreasonable. We do not treat non-PEP-11 Tier supported platforms in this manner (many of which are widely used regardless of active support at PEP-11 standards levels such as other BSDs, Solaris, and AIX). So we should not punish a platform and its users when the last remaining individual keeping it in mere Tier 3 decides that isn’t something they can do with anymore.
Maybe there is a middle ground here where the build fails by default but can be allowed more easily than by patching the build system, by passing an option like --allow-unsupported-platform?
My uninformed opinion worth μ¤ 0.02 is that a lot of people never read warnings, especially on obscure platforms that are just tested by a CI, so failing by default is a good way to avoid the classic “But it was working!! Why break it!!??” “Well, we announced the change long ago.” “But I had no way to know! Do you really expect me to read the changelogs of my 500 dependencies!!?” (as famously happened in cryptography).
I’d like to cast a vote for including a pointer to how to override the
refuse-to-build failure in the warning. An administratively “off” option
with no clear path to turning it “on” is very frustrating.
I believe the original motivation for the error is to notify users who are not keeping up with CPython development and What’s New to know a change to the platform they care about has occurred. I think it was also meant to see if more people would come forward to help support a platform.
Like I wonder how many people know what platforms we do support even if we do happen to compile somewhere? Do they assume it’s officially supported?
And does it matter to them? We handle/close issues based on whether a volunteer wants to work on them. IMO, PEP-11 is mostly a summary of what we want to work on, written for Python devs/triagers – so that you know who to bug for a particular platform, or whether you should “revert first and fix later” when something goes red.
For users, there’s very little actionable information in PEP-11.
Trouble is, they did come forward, and asked what they should do to help support a platform. We have no good answer. And that’s fine, really – it’s OK to do what seems best, and only standardize after it happens a few times. But we should probably acknowledge that Emscripten is in this experimental phase, and do what’s best for it rather than take PEP-11 too literally (and amend it whenever a detail needs changing).
(Sorry for hijacking the thread to talk about the bigger picture. The proposed change is a definite improvement.)
Also, given the widespread availability of binary packages of the CPython interpreter, anyone compiling CPython themselves is pretty much in “expert” territory already. You may display a warning if someone compiles on a non-PEP 11-anointed platform, but I don’t think there’s any value in being stricter.
I’m doing things that (IMO) don’t need explicit SC approval. Feel free to follow along, and stop me you disagree with anything. A proposal will come later, if necessary.
As for Docs, which now have a fancy Editorial Board, my hidden agenda for this ”skunkworks” project is to collect interested people, and keep them interested :‍)
Whoever happens to see it hidden in the morass of build system output. So realistically only someone working to interactively build Python on a platform frequently enough.
I consider it basically an “FYI”. Kind of like we have with the “you know there’s an --enable-optimizations flag that you didn’t use?” message…
I don’t think existing warnings are necessarily well placed, but moving things around so they’re seen perhaps at the end of configure or end of a build isn’t specified (and isn’t going to be specified, lets not overthink it) and is a normal tweak anyone could make via a PR.
No strong objections noticed here and general agreement that we’re don’t proactively break builds on a status change, so I’ve set the PEP-11 update PR to automerge. Thanks everyone!