Defining a support policy on overlapping installations

[stefanor (Stefano Rivera)]

@steve.dower

From… three to two? Or four to three? There aren’t that many suffixes at runtime, and the list of files is already in memory.

@vstinner: These were your concerns, can you take this?

In my testing, I couldn’t even measure any difference.

@steve.dower

From us? Or from people who are even further downstream than Debian?

I have seen some of this from a couple of Python core developers, as well as some people who support Python users on IRC and GitHub. I’m not going to point fingers, especially because things seem to have improved, but please reach out in private if you want examples.

I saw this as a problem, and it pushed me to the point of getting more actively involved in maintaining cPython in Debian, and reducing our patch burden by getting whatever was possible landed upstream. There were some issues in stable releases that lead to some of the unhappiness. I think I got most of them dealt with, and I hope that has resolved a lot of the resentment.

A common response I have seen is “Debian patches Python in weird ways, you should use Python from python.org”. Which is absolutely fair enough. We do patch things, and we break up the stdlib, in ways that I think make sense, but can be confusing to new developers who expect all the batteries to be present. We introduced a python3-full binary package to give you everything you’d expect.

The context for the stdlib splits is that Python is both a programming language, but as an interpreted language it’s also a runtime environment for applications. If you install an app that happens to be written in Python, we don’t install the full X/Wayland stack to give you working TKinter. Instead that’s in a separate package. Same goes for gdbm (for licensing reasons) and ensurepip (for dependency reasons).

@steve.dower

Publicly published wheels from Linux have to go through manylinux processing anyway, right? So there’s already a suitable spot to do the fixup.

Urgh, I really wouldn’t want to rely on that. It seems like loading a footgun…

[stefanor (Stefano Rivera)]

@stefanor

@steve.dower

From… three to two? Or four to three? There aren’t that many suffixes at runtime, and the list of files is already in memory.

@vstinner: These were your concerns, can you take this?

In my testing, I couldn’t even measure any difference.

In the absence of a reply, here was his last reply on the topic: gh-122931: Include multiarch tuple in abi3t filenames by stefanor · Pull Request #122917 · python/cpython · GitHub

[steve.dower]

@stefanor

A common response I have seen is “Debian patches Python in weird ways, you should use Python from python.org”. Which is absolutely fair enough. We do patch things, and we break up the stdlib, in ways that I think make sense, but can be confusing to new developers who expect all the batteries to be present.

Yeah, I’m very familiar with the different expectations between “Python is a system dependency” and “Python is a developer experience”^[1], and personally I think Debian is doing the right thing here. But it’s hard to argue against large groups of users who treat one variant of Python as universally representative and anyone who behaves the slightest bit differently from their preferred variant is critically buggy.^[2]

On this specific issue, I’d say there’s no problem with Debian having the patch, and it’s worth the discussion on whether we apply the same fix upstream. I’m not comfortable making the final call on that, so it may have to go to the Steering Council (not necessarily as a PEP, but certainly with a design and list of pros/cons/risks that they can evaluate).

---

1. I get to deal with the same thing on Windows, both through people regularly arguing Python as a system dependency on Linux as something Windows should copy, and through the various install options we have for our installer. ↩︎

2. IronPython (and I believe PyPy, but won’t speak for them) also suffered from this. ↩︎