[Distutils] Script-specific .pth files (or baking paths into scripts)
ianb at colorstudy.com
Wed May 17 19:55:22 CEST 2006
Phillip J. Eby wrote:
> At 11:50 AM 5/17/2006 -0400, Jim Fulton wrote:
>>I seem to remember a threat from from Phillip to make a proposal
>>for installing script-specific ,pth files with scripts, but I don't
>>think I every saw anything.
> I haven't done it yet, mainly because I haven't decided how it should work,
> exactly. Mostly I'm concerned that it seems to need a bunch of options in
> order to support all the use cases that have been requested.
> For example, you've asked mainly that all the requirements be pre-baked,
> and Ian has asked also that nothing "leak into" the current environment
> that isn't pre-baked. (Which is also a reasonable requirement for
> high-security scripts.)
It's also a reasonable requirement for scripts you don't want breaking
randomly. These continue to be my bane.
What are the use cases? My use cases can be done by inserting something
into the beginning of the path before site is imported. The "something"
can be absolute or a script-relative path. Except for the
script-relative part, it's equivalent to setting PYTHONPATH. If you
don't have a custom site.py, then it's equivalent to just appending it
to the path after site.py is imported.
If this is done through an installation option, then this covers me
(where I have a distutils.cfg controlling this). It can cover script
customization (with setup.cfg), maybe that can be improved by doing some
variable interpolation as well. What variable interpolation I don't
know, as I'm unsure what the actual use case is. I can imagine a use
case where a script represents a complete application, and wants
specific control of all its libraries. But I'm not sure how that fits
in with eggs -- more the basket idea where you get a bundle of things,
and you install the bundle and include it (and only it?) on the path.
I'm all for that too, but there's more to it than just the path issue.
I see the working environment idea as complementary -- the working
environment is what you develop in, and more attention is placed on
making tools like easy_install work in that environment. But if you
want to package it up, you get something more like a basket. So I can
imagine implementing it the same way as the working environment -- you
add a specific path before importing site.py, and the environment/basket
gets to take over there.
So... I guess custom site.py's seem to give script authors a great deal
of flexibility. Except that isn't really a per-script kind of control,
it's more per-basket.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Distutils-SIG