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. ;) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
