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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
