.pth files?

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.

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.

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?

Thanks!

-Ben

insyte@gmail.com

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

<package>.pth naming is just a convention so you can easily sort out the
association for each of multiple pth files. I have a mojam.pth file but no
"mojam" package on my server. Works just fine.

Skip

Skip Montanaro

On Tue, 22 Mar 2005 12:52:28 -0600, Skip Montanaro <> wrote:

> <package>.pth naming is just a convention so you can easily sort out the
> association for each of multiple pth files. I have a mojam.pth file but no
> "mojam" package on my server. Works just fine.

Interesting.

Where does it call home? site-packages?

-Ben

Ben Beuchler

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

Peter Hansen

On 22 Mar 2005 09:29:39 -0800, "" <> 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.
>
>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.
>
>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?
>
>Thanks!
>
I haven't looked at all the ("about 23") hits, but have you tried googling for

pth siteython.org/doc

? The first hit looks promising.

(BTW, for your next python question, try some relevant words in place of "pth" before posting

Regards,
Bengt Richter

Bengt Richter

>> I have a mojam.pth file but no "mojam" package on my server. Works
>> just fine.

Ben> Where does it call home? site-packages?

Yup.

Skip Montanaro