[Distutils] DWIM installation with setuptools

[Phillip J. Eby]

At 12:07 PM 2/11/2006 -0500, Jim Fulton wrote:
>I think you're on the right track, at least from a functionality point of 
>view,
>although I don't want to require a special PYTHONPATH setting to
>use a generated wrapper script.

Just two quick comments: the PYTHONPATH implementation is now in SVN. I 
decided to go with it on the reasoning that the new site.py hack is 
actually less fragile than the old one, because the new one allows any 
vendor-specific site.py patches to take effect, whereas the old one 
didn't.  This allows full DWIM for people who expect PYTHONPATH to 
basically work as it always has without setuptools, and now allows 
installation of any setuptools-based package without any RTFMing 
whatsoever.  :)

Second, now that the PYTHONPATH support works, this provides a stable base 
for your desired environment to be built on.  We only need to have the 
option of building a PYTHONPATH into a generated script (and perhaps also 
generate a script to run the interpreter with a set PYTHONPATH) in order to 
have everything work.  This seems more modular to me than trying to do 
everything in the wrappers.

So, the only things left to figure out at this point are:

1. how the PYTHONPATH wrappers should deal with an existing PYTHONPATH setting
2. how to tell easy_install whether to use PYTHONPATH wrapping and which kind

#2 includes the question of whether scripts should be able to affect the 
wrapping via options specified by the setup script.  In other words, if I 
have a security-sensitive script, should I be able to specify in my setup 
that my script requires a baked-in and frozen PYTHONPATH?  (Mmmm, baked and 
frozen...)

Regarding #1, my first thought is that the most backward-compatible thing 
to do would be to extend the current PYTHONPATH with the one that was in 
effect when the script was installed.  Thus, if you set a PYTHONPATH with 
the intent of overriding something, your wish will still be granted.  (The 
'site' module eliminates duplicate paths, so sys.path isn't elongated in 
the case of duplication.)  You can still break the script by setting 
PYTHONPATH to something that creates a version conflict, but you could do 
that anyway.

The main question, then, is whether this path-freezing should be done by 
default, or whether it should be an option.  My inclination is to make it a 
user-controlled option, at least at first.

Also, this technique has some hurdles to overcome for "traditional" 
distutils scripts (i.e., ones specified with "setup(scripts=[...])"), 
because they don't get .exe wrappers on Windows, and it's not even 
guaranteed that those scripts are Python code.  OTOH, if PYTHONPATH 
freezing becomes popular, I suppose it's just another incentive for people 
to move up to entry-point scripts.  ;)