> Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary. This is fine if you're building and installing Python on a single machine, but it's a problem if you want to pre-build Python and then distribute it to other machines.
> So, for example, when you download Python on Linux (e.g., from python.org), what you're actually downloading is the CPython source, which is then built on your machine.
But python.org does provide prebuilt macOS binaries. How is that accomplished and why doesn't whatever they're doing generalize to Linux?
A big holdup seems to be who would maintain this in the CPython project. Perhaps some Astral folks could become core devs as well and maintain it upstream
Hardly anyone who does real work would want to contribute to CPython these days. The reputational risk is too high, the work would be taken, modified and slowly ruined by the mediocre influencers.
I would advise against Astral for maintaining anything inside the Python organization. Too much talk, power plays and no real software engineering.
The parent comment is inflammatory. That said, moving anything in the Python project requires a lot of energy, there is high friction and it's probably not wise to try to do that until something has established itself outside.
The discussions around lockfiles, dynamic metadata or PyBI (the PEP that wanted to address what python-build-standalone does) are good examples of how hard it is to cause change in that space.
I could never justify the time investment to upstream a lot of my python-build-standalone work. I made some attempts. But it always felt like I was swimming against a heavy current and the talk to meaningful action ratio was too high. The payoff would be there. But it was the kind of work someone would have to pay me to do: not how I would choose to spend my free time on nights and weekends.
I’m optimistic the Astral folks will have better success than me and I support them in their efforts. They have viable, popular solutions in hand. Hopefully that helps convert others to their cause. “If you build it they will come.”
The macOS builds in Python.org are not easy to use for tools like uv and rye. They have hardcoded paths and can only be installed to the one location on the file system. They are also framework builds which is untypical for pythons.
A framework build is a specific build of Python to make it work like a .framework on macOS. The original motivation of this was that you can also ship frameworks within .app bundles but the Python framework build has hardcoded paths so you cannot really do it.
One of the consequences of framework builds is that they have a different layout than a regular Python installation on the file system. The Python installer will also litter a bunch of files into /Applications which makes installing competing versions surprisingly annoying.
In theory a framework build of Python would be preferrable but the framework build would have to become fully relocatable for that benefit to pay off. They are not today.
> So, for example, when you download Python on Linux (e.g., from python.org), what you're actually downloading is the CPython source, which is then built on your machine.
But python.org does provide prebuilt macOS binaries. How is that accomplished and why doesn't whatever they're doing generalize to Linux?