[Pythonmac-SIG] Using embedded python programs from DarwinPorts.
Bob Ippolito
bob at redivi.com
Mon Nov 29 22:52:55 CET 2004
On Nov 29, 2004, at 4:13 PM, Robert White wrote:
> Excuse me for bringing up the following if it has previously been
> discussed and I missed it.
>
> Recently, I started using DarwinPorts again to install
> some programs that I like to have around. However, I noticed that
> several programs that embed Python force an installation of python
> 2.3.4 into DarwinPorts for MacOSX 10.3.6 rather than just using the
> built-in python.
>
> So, in the case of Glom, XChat2 and cvs2svn, I started researching
> how to change the appropriate autoconf et al files to properly link to
> or set up in the builtin Python. (Probably, mostly m4 macros)
> In doing that I contacted two different Port Maintainers asking some
> very basic questions. One stated that "port" is smart enough to use
> the builtin-Python Framework and not pull in the unix version
> which is not my experience. The other stated that "The darwinports
> policy for both perl and python modules is to only use the
> darwinports-provided versions of these languages. The reason is
> that doing something else would require installing files outside of
> the darwinports prefix (which is /opt/local by default).".
port is probably smart enough to bring in Python, but the existing
autoconf scripts, etc. for the packages probably need to be patched. A
lot of them assume -lpython will do the job. What you *could* do is
something like the following to trick them:
ln -s /System/Library/Frameworks/Python.framework/Versions/2.3/Python
/opt/local/lib/libpython2.3.dylib
ln -s /System/Library/Frameworks/Python.framework/Python
/opt/local/lib/libpython2.dylib
ln -s /System/Library/Frameworks/Python.framework/Python
/opt/local/lib/libpython.dylib
ln -s
/System/Library/Frameworks/Python.framework/Versions/2.3/include/
python2.3 /opt/local/include/python2.3
ln -s
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
/opt/local/lib/python2.3
This is probably enough to trick a naive configure script to find your
framework python and link to it correctly without changes.. (untested,
wrote it in mail, didn't want to deactivate my darwinports python to
try it).
> While I find those comments to be justified, I am wondering if it would
> not be possible to use the builtin version if one were to have their
> own PYTHONPATH environment variable defined and otherwise
> pull in a different version. (I am probably wrong, but I think that
> a PYTHONPATH variable addresses most of the problem especially
> if it is pointing back into /opt/local somewhere.)
Well you would have to add extra cruft to the "python setup.py install"
command.. --prefix=/opt/local would be almost sufficient, except that
if you did the trickery above, the headers and the python packages
themselves would go to the wrong place. Unfortunately there isn't
really a right place if the above trickery is used, because the headers
would never really be findable by packages that need them (i.e. pygame
looking for Numeric headers). This is a general problem with
distutils. --install-platlib could put the python packages somewhere
else just fine though (/opt/local/python/2.3/ maybe).
> I know that this ultimately must be presented to the DarwinPorts
> Group, but I know that several on this list are very active there
> and may indicate to me that this is not a worthwhile investment
> of my time. So, I wanted to get your opinions first of whether I
> should
> pursue this or not and if so, any gotchas that you might be aware of.
It's a lot of work, question is do you really want to bother? :)
My only real problem with the darwinports Python is that it uses the
linker option -undefined suppress -flat_namespace (last I checked)... I
personally have a whole bunch of Pythons installed for testing
purposes, so I'm used to the hassle.. though 95% of the time I use the
stock Python 2.3.0. At some point I'm going to start contributing port
and port patches to dp, but I just have high priority things on my
plate right now.
-bob
More information about the Pythonmac-SIG
mailing list