Make ez_setup.py/easy_install $PATH aware
This is hopefully a pretty minor fix, and now that I think about it, I'm surprised it hasn't been in setuptools for ages. Some platforms don't have something setup right so that Python scripts are installed deep into Python library directories that definitely aren't in the $PATH. It becomes embarrassing as one tries to write "Install" instructions, and has to keep including a "Do you have any idea where the XXX command is? Try finding it and adding that dir to your path". Or having to tell people not to do anything without making a ~/.pydistutils.cfg file with a install-dir location. So.... couldn't ez_setup.py look at the $PATH present, and notice when the install location is outside of it? Then it could either give a nice big warning about how the scripts its about to install aren't going to be available without re-installing with the package and defining a install-dir for scripts, or adding the path to your $PATH. Surely there ought to be a better solution than blindly copying scripts into locations that will leave users wondering why they can't be run, and it seems like the system for that should be in ez_setup.py as thats a first step to getting the whole setuptools/ easy_install system going. Thanks, Ben
At 06:04 PM 9/16/2006 -0700, Ben Bangert wrote:
This is hopefully a pretty minor fix, and now that I think about it, I'm surprised it hasn't been in setuptools for ages. Some platforms don't have something setup right so that Python scripts are installed deep into Python library directories that definitely aren't in the $PATH.
It becomes embarrassing as one tries to write "Install" instructions, and has to keep including a "Do you have any idea where the XXX command is? Try finding it and adding that dir to your path". Or having to tell people not to do anything without making a ~/.pydistutils.cfg file with a install-dir location.
So.... couldn't ez_setup.py look at the $PATH present, and notice when the install location is outside of it?
Excellent suggestion, let's add it in 0.7. Patches are of course welcome, or I can just get to it when I get to it. It also needs an option to say "go ahead anyway, I know what I'm doing", or else Jim Fulton will be unhappy. ;-)
Then it could either give a nice big warning about how the scripts its about to install aren't going to be available without re-installing with the package and defining a install-dir for scripts, or adding the path to your $PATH. Surely there ought to be a better solution than blindly copying scripts into locations that will leave users wondering why they can't be run, and it seems like the system for that should be in ez_setup.py as thats a first step to getting the whole setuptools/ easy_install system going.
By the way, it's easy_install that we actually need to worry about, not ez_setup. ez_setup's only job is to download and run easy_install, which then handles everything from there. So both issues can be handled that way. Windows is probably the main offender, here, however, and I'm not sure there's really a good solution there. I don't think there's a standard $PATH directory that really makes sense for all circumstances, to name just one issue. So, suggestions on what should happen there would be helpful.
On Sat, 16 Sep 2006, Phillip J. Eby wrote: [...]
By the way, it's easy_install that we actually need to worry about, not ez_setup. ez_setup's only job is to download and run easy_install, which then handles everything from there. So both issues can be handled that way.
Windows is probably the main offender, here, however, and I'm not sure there's really a good solution there. I don't think there's a standard $PATH directory that really makes sense for all circumstances, to name just one issue. So, suggestions on what should happen there would be helpful.
Perhaps easy_install on Windows should: (I guess step 2. is best done by creating a Windows installer with one of the standard tools (e.g. MSI / msilib)?) 0. Whenever a check is required that executable files are "on the path", call SearchPath(): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/s... 1. Having created a directory for installed Python scripts and set the appropriate registry key at easy_install install time (see step 2), always install Python scripts in that directory. 2. So that easy_install itself can be run without too much user effort, either: a. Always install easy_install.exe to C:\Python2?\Scripts, but warn if it's not on the path. -1 from me, it doesn't seem the "Windows way" to have to have PATH set correctly in order for things to work. b. Create C:\Program Files\PJE\EasyInstall and C:\Program Files\PJE\EasyInstall\Scripts and install easy_install.exe in the latter. Add the appropriate registry key to put the latter "on the path": http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemain4/ht... (where of course C:\Python2? and C:\Program Files would have to be looked up using the appropriate system call / registry key) Of course, it would be even more Windowsy if somebody then wrote a little GUI that allowed you to search PyPI, select projects and click a button to install them. :-) But the other stuff seems much more useful than point & click stuff: it would "just work" for the Windows easy_install target audience -- who surely know how to use the DOS command line, but who like most of us, are easily put off by complicated installation dances involving setting PATH etc. Windows just doesn't really like PATH -- there's even a fairly short fixed limit on the length of PATH &c. you can type into the dialog box when you're setting up the properties of a shortcut (?) to cmd.exe, so if you want to maintain a couple of different "shell" environments that way and you install too many programs, you're out of luck! John
On 9/17/06, John J Lee <jjl@pobox.com> wrote:
On Sat, 16 Sep 2006, Phillip J. Eby wrote:
Windows is probably the main offender, here, however, and I'm not sure there's really a good solution there. I don't think there's a standard $PATH directory that really makes sense for all circumstances, to name just one issue. So, suggestions on what should happen there would be helpful.
Perhaps easy_install on Windows should:
[...]
2. So that easy_install itself can be run without too much user effort, either:
a. Always install easy_install.exe to C:\Python2?\Scripts, but warn if it's not on the path. -1 from me, it doesn't seem the "Windows way" to have to have PATH set correctly in order for things to work.
+1 from me to install C:\Pythonxx\Scripts. -1 on the warning. That's the Python standard for where to install scripts/executables (whether they be .py files or .bat files in the normal case - .exe wrappers fit the same model). It's also what easy_install does right now, as far as I can tell. The "Windows way" is basically to not use the command line at all, so there's no established best practice here. Trying to convince yourself there is one will just result in grief (for you, or your users). Don't get me wrong - I am a Windows user myself, and I use the command line a lot. But I don't see any common approach, and I'm used to tweaking my command line environment to work how I want it to. You *can't* make things work "automatically" for me - and I won't thank you for trying. The best you can do is act like a normal Python package - install to C:\Pythonxx\Scripts and leave me to worry about getting it on PATH. I don't think I'm unusual in this (in the context of the limited set of Windows command line users).
b. Create C:\Program Files\PJE\EasyInstall and C:\Program Files\PJE\EasyInstall\Scripts and install easy_install.exe in the latter. Add the appropriate registry key to put the latter "on the path":
No, no, no. -1000. That works for GUI apps, where the directory doesn't need to be on PATH, and where there are lots of supporting files along with the EXE. But I really don't want to have a directory on PATH just for one or two executables.
Of course, it would be even more Windowsy if somebody then wrote a little GUI that allowed you to search PyPI, select projects and click a button to install them. :-)
That *is* more "Windowsy".
But the other stuff seems much more useful than point & click stuff: it would "just work" for the Windows easy_install target audience -- who surely know how to use the DOS command line, but who like most of us, are easily put off by complicated installation dances involving setting PATH etc.
Not sure how true that is. It certainly isn't for me. My idea of "just works" is bdist_wininst. Double click on it, hit "Next" a few times, and you're done. The key benefit of easy_install over this is that it does dependency handling. But it does so at the cost of needing to use the command line. I'm *still* not convinced that the trade-off is right for me (particularly now that PJE has got setuptools recognising "normal" single-version-externally-managed installs). Arguably, if you have Python installed, you're already using C:\PythonXX\Scripts, so it's either on your PATH or you've made other arrangements. So there's no "installation dance" needed. Please note- it was a deliberate decision to have the Python installer *not* to add C:\PythonXX\Scripts to the PATH. You'll need to search the python-dev archives to get the arguments, but they roughly boiled down to a view that the installer should *not* mess with the user's environment. BTW, if you really want to make easy_install.exe available on the command line without needing a PATH entry, you can do what python.exe does: create a registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe with a single default value of the full pathname for the executable. Then you don't need to muck with the user's PATH at all. For more details, search for "App Paths" in the platform SDK - it gives the full details. Paul.
participants (4)
-
Ben Bangert
-
John J Lee
-
Paul Moore
-
Phillip J. Eby