can you say a bit more about why exactly the app bundle stuff makes it hard to relocate python?
It is certainly possible to make a relocatable Python embedded in an app bundle; that’s exactly what py2app does. But the Python app bundle produced by framework builds isn’t really a GUI app at all: you still need to interface with it exactly like you do a standard (non-framework) Unix build (via stdin et al in a terminal shell, for example) and the current framework build and install steps in the Makefile assume a configure-time fixed install location. So there would be work needed to support invoking Python from the command line (which is 99% of the usage today) for a Python executable in a relocatable app bundle (since the mechanisms today depend on knowing the final install locations at build time), e.g. to install symlinks in /usr/local/bin and/or add the framework bin directory to the $PATH. From an end-user perspective, we don’t do a particularly good job of sanely managing multiple Python versions (especially in the presence of the vendor-supplied system Python); - but that’s a separate issue possibly largely solvable with a py launcher.
The only true Python-based macOS GUI app (i.e. double-clickable icon) we supply today is an IDLE.app bundle in the framework build which, of course, is a (Tk-based) GUI app. It’s also possible to invoke IDLE via the command line; that would also need some hacking to retain the command line functionality with a relocatable Python app.
For completeness sake, I should mention that macOS does provide a mechanism for launching app bundles from a traditional shell: the
open command (inherited from NeXT, I believe). It didn’t use to be possible to pass command line args via argv but that problem has been solved. But I’m quite sure we don’t want to be encouraging users to use that mechanism for lots of reasons, not the least of which would be start up speed.