At 03:53 PM 2/11/2006 -0500, Jim Fulton wrote: >Phillip J. Eby wrote: >>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.
I don't really like that idea; it seems too easy to foul it up by not having the right value(s), since easy_install effectively uses the existing setting to determine whether an installed thing has all its dependencies met. If you are going to be wrapping easy_install in something else anyway, you can just set the PYTHONPATH before the call. That seems a lot safer to me, because then easy_install will be evaluating dependencies properly in the context of the desired PYTHONPATH value. I think what I'm going to have to do to implement this on windows is have an additional foo-script.env file to hold the PYTHONPATH and any other special options. That way, I only have to write or delete that extra file, and everything else works the same. (For 'nix, I'll only need to prepend a /bin/sh header to the script.) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
