[Python-Dev] Python install layout and the PATH on win32
VanL
van.lindberg at gmail.com
Tue Mar 20 20:22:55 CET 2012
More information about the Python-Dev mailing list
Tue Mar 20 20:22:55 CET 2012
- Previous message: [Python-Dev] Python install layout and the PATH on win32
- Next message: [Python-Dev] Python install layout and the PATH on win32
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/20/2012 1:56 PM, Paul Moore wrote: > This is covered (better, IMO) by PEP 397 - Python Launcher for > Windows. Step 2, just run "py". If you prefer a particular version, > run "py -2" or "py -3" or "py -3.2". Interesting. I haven't played around with that at all, so can't comment. I will have to try it out. > Adding python.exe to PATH actually makes this message *worse* as it > confuses the issue. In a post-PEP 397 world, I would say that we > should be telling Windows users *not* to run python.exe at all. > (Unless they are using virtualenvs - maybe PEP 397 could do with an > extra option to run the Python from the currently active virtualenv, > but that's a side issue). I think that having the PATH manipulation be optional might address this issue. I also think that the PEP 397 launcher should respect virtualenvs - at least the built-in pyvenvs - or else there will be lots of confusion. > For your steps 3 and 4, there is certainly user intervention > required as things stand. It would indeed be nice if "regetron" just > worked as expected. But I'd argue a few points here: > > 1. On Windows, if regetron was not explicitly an application for > working with my Python installation (like pip, easy_install, nose, > etc) then I'd prefer it to be packaged as a standalone application > using cx_Freeze or py2exe. I've had too many "applications" break > because I accidentally uninstalled a dependency from my Python > installation to want anything that is an end-user application > installed into my Python scripts/bin directory. Maybe so - and I would probably agree that for any packaged application, bundling it into its own environment (or at least its own virtualenv) is the best practice. But what about pip, easy_install, nose, cython, pygments, PIL, etc, that do this and are meant to be associated with a particular python version? Substitute "nose" for "regetron" if you want, and there is still a problem. > The problem with your example is that it depends on the > package/executable. I looked at regetron (I thought it was a made up > example at first!) ...! I got the name from the feedback I received. I thought it was made up too. > I have no idea what proportion of Python users on Windows have > multiple versions installed. I also have no idea how many such users > work on the command line. My guess would be "not that many" and "not > that many of the first group" respectively... But there are big > groups like scientists and web developers who could sway these > figures a lot. There are a number of casual users that probably only have one version installed, but every python user/dev on windows that I know has one python that they consider to be "python," and everything else needs to be launched with a suffix (e.g., python26.exe). This is usually put earlier on the PATH so that it gets picked up first. For example, right now I have 2.6, 2.7, 3.2, jython, and pypy all installed, and I have "python" pointing to 2.7. > I'd be curious as to how much PEP 397's py.exe would have helped > those people. But yes, it's an issue. Although someone at some point > will have to introduce those beginners to the question of Python 2 vs > Python 3, and PATH pain will hit them then, anyway. I would imagine that it would help steps 1 and 2, but 3 and 4 would be problematic (how can you pip install something using py?) unless you were in a virtualenv, and then (unless py respected the virtualenv) the whole thing would be problematic, because there wouldn't be one clear way to do it.
- Previous message: [Python-Dev] Python install layout and the PATH on win32
- Next message: [Python-Dev] Python install layout and the PATH on win32
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list