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

[Ian Bicking]

Jim Fulton wrote:
> Right. I understood this from the links you gave.  Every program 
> (script) installed
> into the environment has the same path.  If two programs use the same 
> package,
> then upgrading the package for one program updates them all.  I want to 
> avoid
> that.

Then you need more working environments...?  There's not an expectation 
that you'll just use one working environment.  Potentially each 
"application" will use its own working environment, for some definition 
of "application" (it seems like there's several).

> ...
> 
>>> 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,
> 
> 
> That's one of the things we're trying to fake out. :)
> 
> ...
> 
>> 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.
> 
> 
> Yup, that's another example.
> 
>> And then I fake out setuptools, which I'd really rather not do, in 
>> part because my faking out keeps breaking.
> 
> 
> Faking isn't fun.
> 
>> 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 suspect this is a case of too much automation in the wrong place.
> We are tiptoeing around trying to trick setuptools/distutils/site
> into doing the right thing automatically.

Well, there's virtual-python if you really want total trickery.  That 
doesn't feel as scalable, though.

I guess I don't see a way around it.  It would be nice if Python had an 
option like --use-environment=path.  But even if did, because #! works 
in such a weird way, I don't think that wouldn't be enough.  And 
distutils should have a better option, but it doesn't, and that can't be 
changed now.  Ditto site.py.  So these are just the constraints we have, 
short of just replicating and replacing the Python standard library 
entirely.  Which seems rather heavy, since there's only two or three 
things that need adjustment.  Or wait for updates to Python itself, 
which is a particularly unfruitful way to get progress, since most 
people don't seem that concerned about this stuff.  I have no idea why. 
  Are our experience and use cases really so unusual?


But, thinking about it a bit, maybe /usr/bin/python is the wrong entry 
point.  If the interpreter (aka sys.executable) is something that 
"knows" about whatever this thing is -- be it environment or application 
-- then a lot of things might work better.

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