I do that all the time without .pth files -- I just put all the common modules in a package and place the package in the directory containing the "main" .py files.
That's fine as long as you're willing to put all the main .py files together in one directory, with everything else below it, but sometimes it's not convenient to do that.
I had a use for this the other night, involving two applications which each consisted of multiple .py files (belonging only to that application) plus some shared ones. I wanted to have a directory for each application containing all the files private to that application.
> it's too easy to forget about the .pth file and be
confused when it points to the wrong place.
I don't think I would be confused by that. I would consider the .pth file to be a part of the source code of the application, to be maintained along with it. If I got an ImportError for one of the shared modules, checking the .pth file would be a natural thing to do -- just as would checking the sys.path munging code if it were being done that way. And a .pth file would be much easier to maintain than the hairy-looking code you need to write to munge sys.path in an equivalent way.
That's also the reason why I don't use symlinks or $PYTHONPATH for this purpose.
Another reason for avoiding that is portability. My first attempt at solving the aforementioned problem used symlinks. Trouble is, it also had to work on Windows running under Virtual PC mounting the source directory from the host system as a file share, and it turns out that reading a unix symlink from the Windows end just returns the contents of the link. Aaarrghh! Braindamage!
-- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--------------------------------------+ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
