[Distutils] DWIM installation with setuptools

[Jim Fulton]

Phillip J. Eby wrote:
> 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.

I think I agree.

> So, the only things left to figure out at this point are:
> 
> 1. how the PYTHONPATH wrappers should deal with an existing PYTHONPATH 
> setting

IMO, they should honor it, putting it ahead of the bits they want to
add.

> 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? 

Good point. Explicit control. I like it!

 > (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.

This is close, but too implicit, IMO.  I'd rather have an
easy_install option (command-line and config file) to specify the
path that the wrappers should set.

> 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.

Yup.  IMO, this option shouldn't be boolean, but, rather, should
specify the paths to add explicitly.

> 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.  ;)

IMO, the scope should be limited to entry-point scripts.

Thanks for improving this!

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