| Rob Tillotson
|
3
|
 |
|
07-28-2003 06:20 AM ET (US)
|
|
When you run the setup.py to build and install the module, it will be built and installed for whatever version of Python you used to run setup.py.
You should not (and possibly cannot) share binary modules between different versions/builds of Python. The Apple-provided one is a non-framework build of 2.2, and the current MacPython is a framework build of 2.3, so it isn't likely that binary modules will work on both. (On other Unices you can usually import a binary module built for an older version of Python into a newer version, but a warning message will be printed; on OSX there is additionally the issue of framework vs. non-framework, and I'm not sure how that affects binary compatibility. Safest to just build every module twice, if you use both versions.)
Thus, if you want to use the same module with both, run "/usr/bin/python setup.py install", remove the build directory, and run "/usr/local/bin/python setup.py install". You'll end up with a separate copy of the module in each Python's site-packages directory.
It's usually a good idea to do the same for non-binary modules too, at least for ones that are installed by distutils -- you could put them in a shared location, but then the .pycs might be rebuilt every time you import one from a different version of Python from the last time. You should not add the site-packages for one version of Python to the PYTHONPATH while using another version, lest it try to import binary modules in there.
|
| Benko
|
2
|
 |
|
07-28-2003 02:35 AM ET (US)
|
|
for pure python libraries it usually helps if you setup PYTHON_PATH variable to the directory containing the module.
But if it's a library that uses "c" module, it's compiled against specific version of python and it doesn't have to work, anyway, it's worth to test it.
example: setenv PYTHON_PATH=/usr/lib/python2.2/site-packages
|