[Python-ideas] Looking for input to help with the pip situation
gadgetsteve at live.co.uk
Fri Nov 17 05:14:34 EST 2017
On 17/11/2017 09:13, Paul Moore wrote:
> On 17 November 2017 at 01:57, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 17 November 2017 at 05:15, Chris Barker <chris.barker at noaa.gov> wrote:
>>> On Wed, Nov 15, 2017 at 11:07 AM, Steve Dower <steve.dower at python.org>
>>>> 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
>>>> 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:
>> 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 in a venv will still put the regular python executable ahead of the
> 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.
> 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
> 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
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 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.
More information about the Python-ideas