Pixi is another related tool that manages a user’s Python installation needs and could potentially benefit from official Python static binaries:
1 Like
One observation I am making is that more of the world is now sitting on top of @indygreg and I think that is not great. He’s donating a lot of his time to make the standalone builds work. Now obviously rye users are beneficiaries of this work but I know for a fact that these builds have started to show up in companies as the preferred development environment.
I think all of this points to that there is a need for such builds and I would love that this does not fall on the shoulders of a single person.
11 Likes
I have personally brought up wanting to fix this by getting relocatable binaries available on python.org multiple times, but I never get anyone wanting to help who has the knowledge necessary to make it happen. If this has changed and there are people now w/ the right knowledge to try on upstream a solution that can be worked on.
1 Like
Yeah I don’t think anybody from CPython is going to help us here.
I think what needs to happen is an effort to adopt that project if Greg is willing then we have to learn about the changes he’s doing to account for changes to CPython’s building, potentially upstream of those or at least make the maintainers aware of certain hardships, then we need to coordinate to have the outputs signed appropriately (I think only macOS requires that), then we need to ask folks to officially host our outputs.
1 Like
I opened an issue to gather feedback about such an idea and there was a response: Meta: make builds official · Issue #217 · indygreg/python-build-standalone · GitHub
2 Likes
FWIW, I spent some time last week trying to make a private macOS build relocatable, and had it working fine for everything but a few venv and subprocess tests.
But my takeaway is that it’s pretty easily doable, provided we break everyone’s workflows in order to do it 
I don’t think anybody’s workflow would be broken, no? This would simply unlock new workflows.
I struggled to make the current macOS build relocatable without venv tests failing. From our upstream POV, that means venv workflows will stop working with that change. (FWIW, I’m okay with breaking certain venv-based workflows, but ultimately that’s not my personal decision to make.)
I also didn’t go full static either, because important workflows involve having shared libraries. Again, the change will break workflows.
Simply doing additional work to do additional releases might not affect the current set of releases, but asking volunteers to do twice as much work might…
Have you tried running the test suite on Greg’s builds? I’m wondering if there’s not a technical limitation but just something extra he’s doing to make it work.
No, because unfortunately the constraint is that I do my own build, not that it runs standalone (and right now the macOS build isn’t even my main goal, I was just going for completeness).
I would assume the problem is most likely that test_venv is over-specific in something it’s testing. I don’t see any patches in Greg’s repo to Lib/venv/__init__.py, which is what would be needed to fix the default behaviour (assuming you were going to fix it by making venv do more work, which looks like an option).
I can’t tell whether remove-libtool-cruft actually fixes everything I was looking into, but I know that I was overwriting those settings in my build to rely on @rpath names instead, so presumably removing it only solves half the problem (I don’t see any LD_LIBRARY_PATH or DYLD_LIBRARY_PATH references in the docs, and the references in source to install_name_tool look identical to what I came up with).