On 17/11/2017 09:13, Paul Moore wrote: > On 17 November 2017 at 01:57, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 17 November 2017 at 05:15, Chris Barker <chris.bar...@noaa.gov> wrote: >>> >>> On Wed, Nov 15, 2017 at 11:07 AM, Steve Dower <steve.do...@python.org> >>> wrote: >>>> >>>> If you write such a PEP, please also research and write up the issues >>>> with modifying PATH on Windows (they're largely scattered throughout >>>> bugs.p.o and earlier discussions on python-dev). >>> >>> >>> Is anyone proposing doing anything new with that? (other than changing the >>> default) >>> >>>> My preferred solution for this is to rename "py.exe" to "python.exe" >>> >>> >>> I was going to propose that in this thread, but then thought: "there has >>> GOT to be a reason why that reall obvious solution wan't done in the first >>> place", and didn't have time to go back and research it. >> >> >> As far as I recall, the arguments against it are: >> >> - wanting the regular executable and the launcher to be able to coexist in >> the same build target directory >> - not wanting the regular python executable to prevent access to the >> launcher at a shell prompt >> - not wanting the launcher at a shell prompt to prevent access to the >> regular executable at a shell prompt >> >> However, >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-0397%2F&data=02%7C01%7Cgadgetsteve%40live.co.uk%7C18fce28e3baa4e4e70c708d52d9b80c5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636465068254194278&sdata=4%2BAusacb7TwM5NY9xEUXx%2B%2Ff7s%2BTvV05xIhUWtn9xjg%3D&reserved=0 >> doesn't spell those out, >> it just states what the launcher's name will be, and emphasises that the >> main purpose is to provide a sensible target for file associations after the >> "always use the most recently installed version" assumption broke down: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-0397%2F%23rationale&data=02%7C01%7Cgadgetsteve%40live.co.uk%7C18fce28e3baa4e4e70c708d52d9b80c5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636465068254194278&sdata=OVs0HEVnlob8Rj5LQewOE0YoyIvIA9ydar7i0b1%2BZfY%3D&reserved=0 >> >> Addressing them now: >> >> * as long as the extra hard links are only generated at install time, there >> also won't be any problems with build directory name conflicts. >> * the launcher will always be available a `py`, regardless of the current >> PATH >> * PATH in a venv will still put the regular python executable ahead of the >> launcher > > Note that if I *do* get round to working on this, my primary intention > will be to propose altering the launcher to allow it to be used under > different names, as described by Steve. However, I won't initially be > proposing that we add any additional links to the launcher by default, > leaving that for users to do manually, and/or for later revisions of > the PEP (or further PEPs) to propose this. > > Reasons: > > 1. The launcher is typically in C:\Windows, which has a very high > priority on PATH, so getting the environment right will be tricky. > 2. I don't have any real experience with the installer. > 3. Backporting this change, or dealing with older versions of Python > that don't include the new launcher, is a complicated question. > > I'd rather keep the initial PEP restricted to the simple behaviour > change. It's possible that the behaviour change may not even need a > PEP, but I think it'd be better to have one. The "how do we use the > new behaviour in the installers" question is likely to be much more > controversial... > > Paul > > PS This (particularly the replacement of python.exe) is almost > certainly too late for 3.7, so it's not as if there's a rush to answer > all the questions at once :-) > _______________________________________________
Note that renaming py.exe to python.exe would have several problems: 1. It would only address things on Windows or if py were created for other platforms as python there would be issues with trying to ensure that it was the one that was called first in every case. 1. We would have to also rename python.exe to avoid py.exe executing itself. 1. The current behaviour of py.exe doesn't quite match what I was suggesting in that it always executes a python, (the default or specified), or in 3.7 with the -0 lists the ones that it can find, so would not really address the users installing to the wrong context. I was suggesting that pip, and possibly other tools, would simply execute the command if there was only one python in the current context or prompt the user if there were more than one. (It occurs to me that it might also be valuable to have an all option, e.g. for admins installing security updates). I do like the idea to making this sort of behaviour available, possibly as soft-links or alternate entry points, to tools other than pip as that would be very handy in some cases, so having this behaviour in a python library that pip and other tools could invoke would be ideal. (Having it in an external library also takes care of the old installations issue as with back ports & requires.txt it should have a rapid uptake). A soft-link, entry point or batch file option might run something like, (using pydisamb as a possible name), pip.exe = pydisamb -m pip or possibly examining sys.argv[0] and invoking the found or selected python with -m the same name as the invocation if we can find a way to access that, (it will have to give the invocation name for exe, bat, ps1, sh, lnk, etc. to work). -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. http://www.avg.com _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
