Grig Gheorghiu wrote:

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

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.

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

Reply via email to