import problems *newbie*

[Steve Holden]

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