.pth files?

[Peter Hansen]

insyte at gmail.com wrote:
> I'm unclear on how .pth files work.  Some posts imply they can be
> arbitrarily named, as long as they include the .pth extension, and can
> exist anywhere in the current sys.path.  Other documentation seems to
> imply that they must be named <package>.pth, although I'm not sure what
> "package" it would be named after

This is pretty trivial to experiment with.  Two minutes
would make it clear that the name of the file is irrelevant.
So would skimming the source in site.py, though I've found
that takes more like five minutes to piece together as it's
not particular self-documenting and has, as I recall, few
helpful inline comments.

> I used strace to see if I could see which files it was looking for, but
> the output didn't show a single attempted stat() or open() of any .pth
> files.

site.py does not look everywhere, just in a specific,
pre-defined, and platform-specific set of folders, again
defined in the source site.py (I think the written docs
on this miss a few cases).  It also looks in any folders
that are added to the sys.path as a result of being
found in a .pth file (i.e. the search for .pth files is
basically recursive).

> I may be barking up the wrong tree with the .pth files, anyway.  Is
> there a general "best practice" for appending additional directories to
> search for modules?  Specifically, I frequently write utilities that
> depend on a shared module or two that I don't particularly want to
> stick in the "site-packages" directory.  The layout I generally prefer
> is a "lib" dir in the same directory as the assorted scripts.  Clearly,
> I could just do a 'sys.path.append["./lib"]', but that seems kludgy.
> 
> Any clarifications or recommendations?

Look into sitecustomize.py perhaps?  Or PYTHONPATH settings
with a wrapper shell script to set it just for the utilities
in question?

Or do the sys.path.append thing, since it works, is fairly
common practice, and is pretty explicit.

-Peter