[Pythonmac-SIG] Name that Python

Jack Jansen Jack.Jansen@cwi.nl
Tue, 23 Jul 2002 13:01:36 +0200


On Monday, July 22, 2002, at 08:24 , Ronald Oussoren wrote:
>> root# install_name_tool -change Python.framework/Versions/2.3/Python 
>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python 
>> python
>> root# otool -Lv python                     python:
>> ...
>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python 
>> (compatibility version 2.3.0, current version 2.3.0)
>
> If I understand this correctly you don't need to change anything on 
> install if you include the modified copy of python as the python inside 
> an application bundle with a local python framework.
>
> If you'd provide a python that is changed in this way as part of a 
> 'normal' Python.framework install you could use this when building a 
> python application with a local Python.framework instead of the python 
> executable from Python.app. E.g. no need to use install_name_tool in 
> BuildApplication, or even in the python installer (well except for 3th 
> part .so modules, I haven't thought much about those).

I thought along these lines too, but then you can't get command line 
Python to work anymore. Also, using the framework in embedding 
applications and things like the Python scripting component would stop 
working.

The functionality of install_name_tool shouldn't be too difficult to 
duplicate in Python, the structure of MachO binaries appears to be 
pretty straightforward (see /usr/include/mach-o for details). And 
otherwise we would require the developer tools for full BuildApplication 
support. Without the developer tools you would still get partial 
support: BuildApplication can build an application that has all your 
.pyc files in there but would depend on Python.framework.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -