Grig Gheorghiu wrote:
In the long term it doesn't really matter: the fact that my suggestion to use a .pth file worked does leave me still wondering why a PYTHONPATH setting didn't.In my experience (as a tester), it is easier to deal with PYTHONPATH than to add the my.pth file to the site-packages directory. The main reason is that I have my custom packages and modules in a directory tree that I deploy on many clients/servers/platforms/OS versions, some running different versions of Python. I found that I solve my import problems by adding one line to .bash_profile, which sets PYTHONPATH to the parent directory of my custom directory tree. Or, on Windows, I add an Environment variable, call it PYTHONPATH, and set it to the necessary directory. The alternative would be to hunt for the site-packages directory (of which there might be several) on all my systems.
I guess it's a matter of taste in the end, but I do find the PYTHONPATH
approach more suitable for automation and scripting, particularly when
dealing with a large number of systems.
Grig
The advantage of using a .pth file *in the site-packages directory* is that it only applies to the version that picks up that site-packages directory, while PYTHONPATH applies to any Python you happen to run. In the case of libraries this will lead to recompilation of the bytecode (.pyc) files each time a different-version interpreter is used to run the program.
Unless Skip Montanaro's ideas about directing bytecode files to specific locations are picked up, it would seem like a good idea to point out the desirability of using separate copies of Python module sources for different interpreters.
Anyway Mike, I'm glad you have a reliable solution to your problem.
regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
