You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current Python.framework installed by the macOS packages is hard-coded to /Library/Frameworks/Python.framework and breaks if renamed or moved.
A relocatable framework would allow users/admins/developers to install a specific framework to an alternate location, or include it inside an application bundle, or access it from a mounted disk image.
Currently it is possible to use otool and install_name_tool to convert the current framework into one that can be relocated, but doing so breaks any code signing. With Apple Silicon, all executable code and libraries must be code signed, so the effort of relocating the Python framework becomes that more difficult.
Ideally the official macOS framework would be built as relocatable, eliminating the need to modify it and re-sign it to use it anywhere other than /Library/Frameworks/Python.framework.
There's also macholib (which is used by py2app for rewriting mach-o headers).
Note that resigning for arm64 is possible using the following command:
$ codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime -f <path to mach-O>.
This was mentioned in the Xcode 12 release notes.
BTW. My hobby horse w.r.t. a relocatable Python installation is to turn the current framework inside out: have a "Python.app" or "Python 3.10.app" that contains the framework and presents a GUI when double clicked (probably IDLE with some additional menu items). This would simplify the installation experience (no installer, just drop Python.app somewhere convenient).
I have no idea if I'll ever get around to implementing this.
gregneagle commented on Nov 30, 2020
gregneaglemannequin
MannequinAuthor
More actions
A Python.app you could drop somewhere convenient would by definition need a relocatable Python.framework within. :-)
gregneagle commented on Jun 23, 2021
gregneaglemannequin
MannequinAuthor
More actions
While checking this issue hoping there might be updates, I realized that I didn't share a link to the script I use to convert python.org's Python framework into one that can be relocated.
I have struggled with this exact issue in my py-js project (https://github.com/shakfu/py-js) which embeds a python3 interpreter in a max/msp plugin or in a relocatable folder (package) structure. For the latter case, Greg's solution, which is based on standard methods, has been absolutely crucial. Thank you!
I have found that trying to do the same with a python distro built with --enable-shared is basically impossible because in this case sys.prefix is hardcoded and it dos not respond (like the framework structure) to the same @rpath methods used by Greg.
It would be great for those who embed python for a fun or profit to have these issues addressed across all of the standard build structures.
FWIW, Sigil the epub editor embeds a relocatable python3 framework inside on macOS but the way to create it involves a lot of manual rpath tweaking and post build changes. Recent _sysconfig_data* and pkg-config files makes it even harder. The version we build and embed suffices for the needs that Sigil has to make python run its plugins.
Activity
gregneagle commentedon Nov 30, 2020
The current Python.framework installed by the macOS packages is hard-coded to /Library/Frameworks/Python.framework and breaks if renamed or moved.
A relocatable framework would allow users/admins/developers to install a specific framework to an alternate location, or include it inside an application bundle, or access it from a mounted disk image.
Currently it is possible to use
otoolandinstall_name_toolto convert the current framework into one that can be relocated, but doing so breaks any code signing. With Apple Silicon, all executable code and libraries must be code signed, so the effort of relocating the Python framework becomes that more difficult.Ideally the official macOS framework would be built as relocatable, eliminating the need to modify it and re-sign it to use it anywhere other than /Library/Frameworks/Python.framework.
ronaldoussoren commentedon Nov 30, 2020
There's also macholib (which is used by py2app for rewriting mach-o headers).
Note that resigning for arm64 is possible using the following command:
This was mentioned in the Xcode 12 release notes.
BTW. My hobby horse w.r.t. a relocatable Python installation is to turn the current framework inside out: have a "Python.app" or "Python 3.10.app" that contains the framework and presents a GUI when double clicked (probably IDLE with some additional menu items). This would simplify the installation experience (no installer, just drop Python.app somewhere convenient).
I have no idea if I'll ever get around to implementing this.
gregneagle commentedon Nov 30, 2020
A Python.app you could drop somewhere convenient would by definition need a relocatable Python.framework within. :-)
gregneagle commentedon Jun 23, 2021
While checking this issue hoping there might be updates, I realized that I didn't share a link to the script I use to convert python.org's Python framework into one that can be relocated.
It's here: https://github.com/gregneagle/relocatable-python
macmule commentedon Jun 30, 2021
Just wondering if any movement on this etc.
This is something I've been struggling with too, and have attempted to overcome via Greg's project to no avail.
ronaldoussoren commentedon Jul 1, 2021
I guess Ned and I are the only core devs that would be vaguely interested in working on this. I have no active plans to work on this.
Having a relocatable framework would be nice, but doing this in a way that maintains all functionality, esp. w.r.t. the Python executable.
shakfu commentedon Mar 14, 2022
I have struggled with this exact issue in my py-js project (https://github.com/shakfu/py-js) which embeds a python3 interpreter in a max/msp plugin or in a relocatable folder (package) structure. For the latter case, Greg's solution, which is based on standard methods, has been absolutely crucial. Thank you!
I have found that trying to do the same with a python distro built with --enable-shared is basically impossible because in this case sys.prefix is hardcoded and it dos not respond (like the framework structure) to the same @rpath methods used by Greg.
It would be great for those who embed python for a fun or profit to have these issues addressed across all of the standard build structures.
kevinhendricks commentedon Jul 23, 2023
FWIW, Sigil the epub editor embeds a relocatable python3 framework inside on macOS but the way to create it involves a lot of manual rpath tweaking and post build changes. Recent _sysconfig_data* and pkg-config files makes it even harder. The version we build and embed suffices for the needs that Sigil has to make python run its plugins.
See:
https://github.com/Sigil-Ebook/Sigil/blob/master/docs/Building_A_Relocatable_Python_3.11_Framework_on_MacOSX.txt
So a way to make things relocatable via the build itself would be quite useful.
johnzhou721 commentedon May 2, 2025
FWIW & FYI: https://github.com/beeware/Python-Apple-support has a Makefile which has a target to build a relocatable for macOS by doing some stuff on the official non-relocatable build.