[Pythonmac-SIG] Python Framework

[Jack Jansen]

Recently, William Noon <noon@snow.cit.cornell.edu> said:
> When installing, it only copied over the Versions tree and didn't make
> the symbolic links for Headers, Resources and Python.  It also didn't 
> create the bin, lib, include and man directories.  I brought these
> over by hand and made the appropriate links.

Did you use "make frameworkinstall"? It should first do "make install"
to put a standard Python installation (bin, lib, etc) into
/Library/Frameworks/Python.framework/Versions/2.2 and then a "make
frameworkinfrastructureinstall" which creates the symlink jungle.

> I need to use the command
> line version so I made a link from
> /Library/Frameworks/Version/Current/bin/python.exe -> /usr/local/bin/python
> Even once the Python.app is set, I think we will need a python in
> the std bsd PATH somewhere.

Yes, we definitely need this too. But: at this point we don't know
where the user would like it, as we've overridden $(prefix) to point
to the location where we want it.

One thing we could do is add an extra target ("make cmdlineinstall"?)
and stuff the symlinks into /usr/local. Does anyone have better ideas?

> It looks like some more magic is needed in Modules/getpath.c to 
> get the sys.path and sys.prefix and sys.executable to point to the
> right place.  sys.path includes the build directories but not the
> real libs.

This is funny. It may be another symptom of the next problem, or it
may be that your framework installation isn't complete. getpath.c
looks at <frameworkbase>/Lib/python2.2/os.py, and if it doesn't exist
it assumes it is running with the "skeleton framework" which is
created in the build directory. So either it really is doing that
(see below) or your /Library/yaddayadda installation is incomplete.

> sys.executable/sys.prefix will try to execute the 
> Python library at Versions/2.2/Python.  This specifically shows up when
> building the mxBase stuff.  Other, simple modules (like bsddb3) work fine.

Are you sure sys.prefix is pointing to the local copy too? I always
see sys.prefix as /Library/tralala, even when running with the local
copy of the framework and sys.path pointing to the build directories.

There is some magic here, though. Tony came up with the elegant solution of
referring to the framework not by its full /Library/tadidadida path
but by a relative path starting with
Python.framework/Versions/2.2. Due to the dyld search code this works
great in 2 situations:
1) You're running from the build directory, Python hasn't been
installed yet and you're trying to run, say, setup.py.
2) Python has been installed, and you're not in the build directory.

You now have a third case:
3) You're in the build directory, but Python has been installed and
you would like to use that version. However, dyld prefers the
Python.framework in the local directory over that in the
/Library/Frameworks directory.

I'm not sure I understand how sys.prefix can be wrong. And I assume
that that's the only one that really matters, or not? Could you pleaee
investigate a bit more?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm