Build1 publisher2 min readPublished
Ned Deily asks whether CPython should still ship macOS installers after stretches of solo upkeep
Ned Deily asked the 2026 Python Language Summit whether CPython should keep shipping macOS installers that carry 25 years of technical debt. Nobody knows whether anyone would miss them, because the project has not measured who installs Python from python.org on a Mac.
The Engineer · Build desk
What happened
- Deily said shipping the installers had continued mostly on "autopilot", and for stretches that were "too long" he was the only person maintaining them.
- Homebrew, MacPorts, Conda, uv, ActiveState and Apple's Xcode each build their own macOS Python and use none of the python.org builds.
- Łukasz Langa asked whether the Python Developers Survey covers macOS installers, and Deily agreed that asking would be a good idea.
- Deily noted that PEP 11 has no section for macOS.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Keeping the installers means other core developers must learn which of their changes affect macOS, a knowledge transfer Deily called "long-past due".
- exposure Dropping the installers would leave py2app, which Deily said builds on the Framework builds, looking for another source for a build it already has to "munge".
- decision Whether to keep or drop the installers depends on whether the IT departments and schools Deily guessed at could switch to a distribution that builds its own Python.
A CPython release is mainly source code: tarballs and ZIP archives that downstream packagers build for their own platforms [2]. Windows and macOS also got pre-compiled installers, because the two platforms were "different" [3]. Deily's case for revisiting the Mac exception is that "macOS has come a long way" and is no longer comparable to Windows "in terms of strangeness" [4].
Some of the difference is still real. macOS has three build types: static and shared, which behave like Unix builds, and framework, which exists only on macOS and iOS [8]. Apple's developer tools build what Deily called "fat files", single objects holding ARM64 and x86-64 code, and ship a Clang that handles the multi-architecture linking [9]. SDK headers and libraries live inside the SDK, not under /usr [10]. One environment variable switches SDK versions, so a single Mac can build for iOS, or for Intel macOS on Apple Silicon [10]. The Framework build is the part I would protect whatever happens to the installer. Deily said it lets a developer embed Python in a Mac app that "just works everywhere with no external dependencies" [11].
The installer built on top of it ignores macOS guidelines for file layout and does not support sandboxing [12]. Sandboxing is required for distribution through the App Store [12]. There is only one system-wide install location, and the Framework version numbers do not line up with Python's because of ABI compatibility [13]. Free-threading added a second, separate Framework build for python3t [14]. Deily does not expect that split to last once free-threading becomes the default [14].
On who would miss the installers, Deily had guesses and no data. "We don't know, but we can make some guesses", he said [15]. His profile was "users on managed system environments such as centralized IT departments, public schools, engineering or scientific users, novice programmers, and experimenters" [15]. A developer who gets Python from any of the six distributions Deily named is outside the decision, since each one builds its own [1]. The summit record does not show that the python.org installer is how most teams put Python on a Mac.
The maintenance question also extends beyond the Mac. "A lot of what happens for macOS also applies to iOS", Deily said, noting that the project now provides compiled binaries for iOS as well [7]. It was the first time the topic had come up in 15 years of Language Summits, Deily said [1].
What to watch
- Whether the Python Developers Survey adds a question on macOS installer use, as Łukasz Langa suggested.
- Whether a macOS section is drafted for PEP 11.
- Whether the separate python3t Framework build is folded back into the main one once free-threading becomes the default.