[Distutils] Script-specific .pth files (or baking paths into scripts)

[Ian Bicking]

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