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

[Ian Bicking]

Jim Fulton wrote:
>> 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? 
> 

Well, here's how workingenv deals with some of these right now...

> I want to be able to install multiple programs ("scripts"), each with their
> own dependencies.  Note that different programs might depend on
> different versions of the same package.

Inconsistent requirements in a single working environment rely on 
setuptool's multiversion install, which should work fine on its own when 
used in limited places.

> I want to be able to update a package for one program without
> implicitly affecting the others.  (This is a restatement of your
> desire not to get implicit updates)

This is fine.

> I want everything to be installed in a self-contained project,
> ala your working environment.  I don't want to touch a Python install.

Yup.

> I to be able to use a simple install script, like easy_install.

Except for frequent breakage, this works.  I hope that breakage is 
transitional.  Also, the python console works fine and represents the 
working environment, not the larger environment.

With workingenv, I also am playing around with --requirements, which is 
kind of a complete installation plan.  I think an external list of 
requirements is much easier to maintain than packages that carry their 
own requirements; at least for a certain set of problems, like 
co-developed packages, and building consistent development environments 
from code that is actively developed.  Or just building a development 
environment at all, as when you are building a web application.

> I don't want to have to set environment variables or provide funny
> options when I run programs.  I'd like to minimize this when installing 
> things.

When the setuptools monkeypatch works, this is fine.

> I want the system to be simple and understandable.  I'm willing to 
> sacrifice
> a lot of automation for this. "Explicit is better than implicit." :)

Except for some (IMHO necessary) faking out of bits and pieces, 
workingenv is really just a matter of setting the path and keeping the 
path from being implicitly extended.  So I think it's quite simple.  It 
would be nice if Python proper was so simple to work with, but I'm not 
100% sure what I really want yet, and I really don't feel like the grief 
of proposing anything on python-dev.  And anyway, I need this to work 
with old Python versions.

Perhaps one personal motivation is that I don't like to give lots of 
options to tools, I would rather they just work correctly, because any 
option I give is something I might give incorrectly.

That said, having to use /path/to/env/bin/easy_install doesn't bother 
me, even though easy_install --prefix=/path/to/env *does* bother me, so 
maybe workingenv can be a little simpler if I give up completely on 
integrating with any larger system of packages.

> It should be possible to move or link scripts around.  It is not a 
> requirement
> for me to be able to move an environment without running some program to
> adjust paths, as long as such a program exists.

Scripts can't be moved at this time.  The entire environ can be moved, 
though the activation scripts have to be adjusted, because I haven't 
figured out a way to do script-relative paths in a shell script that is 
sourced.  If you don't use the activation script, then that's fine.  And 
maybe the only thing that really needs the activation script is the 
python interactive interpreter.

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