[Distutils] DWIM installation with setuptools
jim at zope.com
Sat Feb 11 21:53:02 CET 2006
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
IMO, they should honor it, putting it ahead of the bits they want to
> 2. how to tell easy_install whether to use PYTHONPATH wrapping and which
> #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!
> 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 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
More information about the Distutils-SIG