On 20 March 2012 14:27, VanL <van.lindb...@gmail.com> wrote: > Germane to this discussion, I reached out for feedback. Most people didn't > care about the issue, or were slightly inclined to have it be uniform across > platforms. > > As Terry mentioned, I think that long-term uniformity will benefit everybody > down the line, and that is the way to go. > > The most interesting feedback, though, related to moving the Python exe and > placing it on the PATH. I got one argument back that I thought was > persuasive here: We want things to 'just work.' Specifically, the following > sequence of events should not require any fiddling on Windows: > > 1. Install python. > 2. Open up a shell and run "python" > 3. Use pip or easy_install to install regetron (a package that installs an > executable file). > 4. Run regetron. > > For step #2, the python exe needs to be on the PATH. For steps 3 and 4, the > binaries directory needs to be on the PATH.
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". 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). If we do put python.exe on PATH (whether it's in bin or not), we have to debate how to handle people having multiple versions of python on their machine. In a post-PEP 397 world, no Python is "the machine default" - .py files are associated with py.exe, not python.exe, so we have to consider the following 3 commands being run from a shell prompt: 1. myprog.py 2. py myprog.py 3. python myprog.py 1 and 2 will always do the same thing. However, 3 could easily do something completely different, if the Python in the #! line differs from the one found on PATH. To me, this implies that it's better for (3) to need explicit user action (setting PATH) if it's to do anything other than give an error. But maybe that's just me. I've been hit too often by confusion caused by *not* remembering this fact. Note: I am using Vinay's py.exe all the time these days, so my comments about a "post-PEP 397 world" are from my direct experience. 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. 2. If regetron is not an end-user application, it should really be getting installed in, and run from, a virtualenv. And in that case, activating the right virtualenv is part of the workflow. And that sets up PATH as needed, so there's no problem here. 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!) and it seems clear to me that it should either be packaged up with py2exe/cx_Freeze, or (if it's sufficiently version-independent) sit outside of Python's installation tree. I can't see any reason why I'd expect a "regetron" command to work or not depending on which copy of Python on my PC I have active. But other applications may differ, I guess. I concede that the picture is much simpler when people only ever have a single version of Python on their machine. So for that case alone, maybe the "Make this Python the default" option in the installer should add the bin directory (or Scripts and the root, under the current layout) to the PATH. But equally, if the installer detects another copy of Python already installed, it should probably warn the user loudly that it's important to understand the implications of setting "make this Python the default", and should not set it by default (this may be the current behaviour, I don't know). 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. > In hearing from a couple people who teach python to beginners, this is a > substantial hurdle - the first thing they need to do is to edit their > environment to add these directories to the PATH. 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. > This is orthogonal to the Scripts/bin issue, but I thought it should be > brought up. Agreed (both that it's orthogonal and that it should be discussed). Once Python 2 is dead and gone, these issues will be a lot simpler - but I don't think that's going to be for a few years yet. Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com