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

[Ian Bicking]

Jim Fulton wrote:
> Ian Bicking wrote:
> 
>> 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.  Have I missed anything?  If so, what? :)
>>> If not, I'll probably write something myself and share it.
>>
>>
>>
>> workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't 
>> use .pth files, but does put in script-specific paths.
> 
> 
> As I understand it, it is really putting in environment-specific paths.
> I think I want script-specific paths.

I don't think I understand the distinction?  Specifically, this is what 
gets put in:

#!/usr/bin/python2.4 -S
import sys, os
join, dirname = os.path.join, os.path.dirname
lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % 
tuple(sys.version_info[:2]))
sys.path.insert(0, lib_dir)
import site
# EASY-INSTALL-SCRIPT: 'Cheetah==1.0','cheetah'
__requires__ = 'Cheetah==1.0'
import pkg_resources
pkg_resources.run_script('Cheetah==1.0', 'cheetah')


I.e., it's hardcoding ../lib/python2.4 into the path.  The relative 
directory is right for workingenv (it makes it movable), but an absolute 
location might be what you want.  That's not very different, really.

The "environment" is really built off this path override, not the other 
way around.  The path override is in turn picked up from the environment 
during installation, but that's just a matter of self-consistency.

>> As I note in my previous email ("setuptools: hardcoding the path in a 
>> script and site.py"), I think this would probably be cleanest to do 
>> through a new installation option, that could also be placed into 
>> distutils.cfg.  Right now what workingenv does is very specific to 
>> workingenv, and doesn't work off any public setuptools API.
> 
> 
> I have an intuition that we're thinking about this incorrectly.
> We seem to be going through a lot of effort to fake out something,
> athough I'm not sure what. 

Primarily I'm trying to fake out site.py, which is the source of most of 
my problems.  It's a reasonable implementation of one packaging 
scenario, but it's hard to replace, and the standard implementation 
isn't what I want.

I also want to fake out distutils slightly, mostly to provide my own 
distutils.cfg, which is again a good idea that is far harder to use than 
it should be.

And then I fake out setuptools, which I'd really rather not do, in part 
because my faking out keeps breaking.

Oh, and faking out of #!, which if it wasn't so obnoxiously useless 
would be sufficient to handle the path stuff on its own.

> I have a growing suspiction that
> the traditional model of a large namespace of modules
> that is used by many applications serves simple scripting very well
> but doessn't work well for applications.

Absolutely, that's what I feel as well.  I want to opt-in to modules, 
not get some huge cloud.  At this point, setuptools/easy_install 
actually makes that cloud expand much more quickly with multi-version 
installations, and that's caused real problems for me.



-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org