Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?
[Replying to a mail that was sent before I joined this list. Quoting, headers, etc. aren't exactly right.] Nick Coghlan wrote:
On 4 October 2014 10:51, Donald Stufft <donald at stufft.io> wrote:
Whoops, I misred.
So to be clear, you think:
install -> pip, pip2, pip2.7 altinstall -> pip2.7
To spell out the assumption I didn't make clear when helping with the backport PEP, the difference comes from PEP 394, which specifies the following behaviour when installing Python itself:
Python 2.7: python, python2, python2.7 Python 3.4: python3, python3.4
That maps to ensurepip as:
Python 2.7: pip, pip2, pip2.7 Python 3.4: pip3, pip3.4
I just installed Python 3.4.2 on Windows and noticed that its Scripts directory has these files out-of-the-box: easy_install.exe easy_install-3.4.exe. pip.exe pip3.exe pip3.4.exe Based on Nick's explanation above, having pip.exe there looks like bug in the installer and could easily cause a conflict with other pip installations. I don't understand why easy_install is included there in the first place, but easy_install.exe can obviously cause a similar conflict. Cheers, .peke -- Agile Tester/Developer/Consultant :: http://eliga.fi Lead Developer of Robot Framework :: http://robotframework.org
On Wed, Oct 22, 2014 at 6:15 AM, Pekka Klärck <peke@iki.fi> wrote:
[Replying to a mail that was sent before I joined this list. Quoting, headers, etc. aren't exactly right.]
Nick Coghlan wrote:
On 4 October 2014 10:51, Donald Stufft <donald at stufft.io> wrote:
Whoops, I misred.
So to be clear, you think:
install -> pip, pip2, pip2.7 altinstall -> pip2.7
To spell out the assumption I didn't make clear when helping with the backport PEP, the difference comes from PEP 394, which specifies the following behaviour when installing Python itself:
Python 2.7: python, python2, python2.7 Python 3.4: python3, python3.4
That maps to ensurepip as:
Python 2.7: pip, pip2, pip2.7 Python 3.4: pip3, pip3.4
I just installed Python 3.4.2 on Windows and noticed that its Scripts directory has these files out-of-the-box:
easy_install.exe easy_install-3.4.exe. pip.exe pip3.exe pip3.4.exe
Based on Nick's explanation above, having pip.exe there looks like bug in the installer and could easily cause a conflict with other pip installations. I don't understand why easy_install is included there in the first place, but easy_install.exe can obviously cause a similar conflict.
Nick's explanation is based on PEP 394, which explicitly does not apply to Windows. The Windows Python executables are called "python.exe" and "pythonw.exe"; no "3" has ever been part of the name and it's not surprising that there's a matching "pip.exe". The pip3.exe and pip3.4.exe being installed are actually the anomalies here, but I wouldn't call them a bug.
On 22 October 2014 21:10, Geoffrey Spear <geoffspear@gmail.com> wrote:
On Wed, Oct 22, 2014 at 6:15 AM, Pekka Klärck <peke@iki.fi> wrote:
I just installed Python 3.4.2 on Windows and noticed that its Scripts directory has these files out-of-the-box:
easy_install.exe easy_install-3.4.exe. pip.exe pip3.exe pip3.4.exe
Based on Nick's explanation above, having pip.exe there looks like bug in the installer and could easily cause a conflict with other pip installations. I don't understand why easy_install is included there in the first place, but easy_install.exe can obviously cause a similar conflict.
Nick's explanation is based on PEP 394, which explicitly does not apply to Windows. The Windows Python executables are called "python.exe" and "pythonw.exe"; no "3" has ever been part of the name and it's not surprising that there's a matching "pip.exe". The pip3.exe and pip3.4.exe being installed are actually the anomalies here, but I wouldn't call them a bug.
Right, the design on Windows is a little different, as the Python 3 executable has always remained "python.exe" there. Originally we followed PEP 394 style naming on Windows as well, but then realised during the 3.4 beta cycle that doing so didn't actually make sense (see http://bugs.python.org/issue20568 and http://bugs.python.org/issue20139) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Geoffrey Spear -
Nick Coghlan -
Pekka Klärck