[Distutils] Script-specific .pth files?

[Jim Fulton]

Phillip J. Eby wrote:
> At 04:19 PM 2/11/2006 -0500, Jim Fulton wrote:
> 
>> Here's a nutty idea I thought of when thinking about some of the
>> recent back and forth.
>>
>> I realized, when thinking about "plugins" versus "scripts" is
>> that a key use case is getting a script installed so that it will
>> run. A script comes from an egg, which depends on other eggs, and
>> so on.  (Of course, this gets more exciting for complex script,
>> like, say, Zope. :)
>>
>> It occurs to me that, when a script is installed, easy_install
>> could generate a .pth file that named exactly those eggs the script
>> needed. A wrapper script could be generated that used this .pth file.
> 
> 
> It'd have to be some other extension, to avoid confusing a 
> normally-started Python that happens to be processing .pth files in that 
> directory.

Sure.

> The code could be as simple as:
> 
>    sys.path[:0]=[line.strip() for line in open(__file__+'.eggs','r')]

Yup. This is another argument for not using a .pth suffix, as
then all we expect is a list of file names, wheras a .pth file
can theoretically be a lot more complicated.

> 
>> There wouldn't be any need for run-time analysis.  The script wouldn't
>> need to manipulate PYTHONPATH to find the needed eggs, as all of the
>> needed eggs would be captured in the script-specific .pth file.
>> Rather than determining the working set at run time, the working set
>> would be determined at install time.
>>
>> I see a number of advantages to this approach:
>>
>> - No complicated run-time path gymnastics
>>
>> - Faster start-up, as there is no run-time searching for eggs
>>    or analysis of which eggs to use
> 
> 
> It's not actually going to eliminate the processing, unless the 
> importing of the entry point gets hardcoded into the script, such that 
> it no longer uses the entry point mechanism to locate the entry point at 
> runtime.  I'm not sure I want to do that, in part because this data is 
> more fragile if you move things around.  Right now, you can upgrade a 
> dependency of a package without needing to reinstall the depender, 
> because the paths get fixed up at runtime.  Skipping the dynamic 
> resolution would break if you remove an older version of something on 
> upgrade.

Yup. This is a tradeoff.  Run-time analysis is more flexible.
The idea I threw out trades off flexibility for the benefits I
mentioned.

...

 > Hm.  This just might work.

:)

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org