Anyone who has a windows machine mind testing some installers for me? These should install pip and setuptools: https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi Let me know? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 03/10/2013 15:11, Donald Stufft wrote:
Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi
They all install and appear to have dropped the right files in the right place. Haven't actually tried installing anything yet! TJG
On 03/10/2013 15:20, Tim Golden wrote:
They all install and appear to have dropped the right files in the right place. Haven't actually tried installing anything yet!
Sorry... that obviously got caught in moderation; I sent it a day ago. Fairly useless now given Steve's extensive testing & analysis! TJG
Successfully tested on Windows 7 (64-bit) running Python 2.7.5 (32-bit). I
tested pip installing a distribution and importing setuptools.
This appears intentional but I'll just mention it just in case:
I have to specify the full path (i.e., C:\Python27\Scripts\pip) on the
command-line to execute pip.
"python -m pip" works though.
On Thu, Oct 3, 2013 at 10:11 AM, Donald Stufft
Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi
Let me know?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 4 Oct 2013 02:13, "Vladimir Diaz"
Successfully tested on Windows 7 (64-bit) running Python 2.7.5 (32-bit).
I tested pip installing a distribution and importing setuptools.
This appears intentional but I'll just mention it just in case: I have to specify the full path (i.e., C:\Python27\Scripts\pip) on the
command-line to execute pip.
"python -m pip" works though.
Yeah, the CPython installers currently don't add the scripts directory to PATH. 3.4 is likely to change that. Thanks for checking! Cheers, Nick.
On Thu, Oct 3, 2013 at 10:11 AM, Donald Stufft
wrote: Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi
Let me know?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against: WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64 With Python 2.7.5, 3.2.3 and 3.3.2, x86 and x64 for each. (It helps to have a bit of practice with large test matrices, convenient access to clean VMs for lots of operating systems, and a couple of internal automation tools :) ) One issue I noticed is that if you've previously installed pip from source and it's in easy-install.pth, the version from the MSI won't be used when it is installed. The same applies to setuptools. (I used setuptools 0.9.8 and pip 1.3.1 for testing this.) In general there don't seem to be any other problems with it. I've noted some possible issues below, but since I don't know how much control you have over these, please don't take it personally if I'm pointing out things that cannot be changed. - the default value for specifying a manual path ("D:\PythonX") should probably be "C:\PythonXY" where XY is the version the installer is targeting. - 64-bit versions of Python installed for all users are not detected. Are you planning a 64-bit version of this installer? (Specifying the path manually worked fine.) - the RemoveFile table is incorrect for Python 3.x - there are no references to __pycache__ folders, only to .pyc and .pyo files in the same folder as their .py counterpart. As a result, uninstall is not clean for Python 3.2 and 3.3. In particular, Python 3.3 will show this (instead of "No module named pip"): C:\ >C:\Python33\python.exe -m pip Traceback (most recent call last): File "C:\Python33\lib\runpy.py", line 140, in _run_module_as_main mod_name, loader, code, fname = _get_module_details(mod_name) File "C:\Python33\lib\runpy.py", line 105, in _get_module_details if loader.is_package(mod_name): AttributeError: 'NamespaceLoader' object has no attribute 'is_package' - choosing between 'All Users' and 'Just For Me' in the pip installer didn't seem to affect the install location. - uninstalling Python before pip worked fine. (No problem here, just letting you know that I tried it :) ) - selecting both install options (Python from registry/custom path) and specifying the same path worked fine Caveats: - all machines were clean OS installs + Python from python.org. I didn't try installing Python from other sources - I only tested upgrading pip with the installer on Windows 8, but I'm confident it will behave the same on all other platforms All up, it looks great, and it's going to make things much easier for Windows users. Thanks for doing this. Cheers, Steve -----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+steve.dower=microsoft.com@python.org] On Behalf Of Donald Stufft Sent: Thursday, 3 October 2013 0712 To: DistUtils mailing list Subject: [Distutils] Test Windows Installers Anyone who has a windows machine mind testing some installers for me? These should install pip and setuptools: https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi Let me know? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Oct 3, 2013, at 5:59 PM, Steve Dower
I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against:
WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64
With Python 2.7.5, 3.2.3 and 3.3.2, x86 and x64 for each. (It helps to have a bit of practice with large test matrices, convenient access to clean VMs for lots of operating systems, and a couple of internal automation tools :) )
One issue I noticed is that if you've previously installed pip from source and it's in easy-install.pth, the version from the MSI won't be used when it is installed. The same applies to setuptools. (I used setuptools 0.9.8 and pip 1.3.1 for testing this.)
What do you mean for this? That if you already have pip 1.3.1 installed and you install from the MSI when it's over the installed version is still 1.3.1?
In general there don't seem to be any other problems with it. I've noted some possible issues below, but since I don't know how much control you have over these, please don't take it personally if I'm pointing out things that cannot be changed.
- the default value for specifying a manual path ("D:\PythonX") should probably be "C:\PythonXY" where XY is the version the installer is targeting.
Hmm, I'll see what I can do about this, I'm reusing routines from distutils to handle this but I may have some level of control over that.
- 64-bit versions of Python installed for all users are not detected. Are you planning a 64-bit version of this installer? (Specifying the path manually worked fine.)
Yea that was pointed out to me, I'll probably make 64bit installers since I don't think a 32bit installer can detect the 64bit versions.
- the RemoveFile table is incorrect for Python 3.x - there are no references to __pycache__ folders, only to .pyc and .pyo files in the same folder as their .py counterpart. As a result, uninstall is not clean for Python 3.2 and 3.3. In particular, Python 3.3 will show this (instead of "No module named pip"):
This is going to be an issue with distutils again, I'll see if I can control it but it'd probably be a good idea to get this fixed in distutils too.
C:\ >C:\Python33\python.exe -m pip Traceback (most recent call last): File "C:\Python33\lib\runpy.py", line 140, in _run_module_as_main mod_name, loader, code, fname = _get_module_details(mod_name) File "C:\Python33\lib\runpy.py", line 105, in _get_module_details if loader.is_package(mod_name): AttributeError: 'NamespaceLoader' object has no attribute 'is_package'
- choosing between 'All Users' and 'Just For Me' in the pip installer didn't seem to affect the install location.
AFAIK distutils added that, no idea what it does or means. I'll see if I can remove it.
- uninstalling Python before pip worked fine. (No problem here, just letting you know that I tried it :) ) - selecting both install options (Python from registry/custom path) and specifying the same path worked fine
Caveats: - all machines were clean OS installs + Python from python.org. I didn't try installing Python from other sources - I only tested upgrading pip with the installer on Windows 8, but I'm confident it will behave the same on all other platforms
All up, it looks great, and it's going to make things much easier for Windows users. Thanks for doing this.
Cheers, Steve
-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+steve.dower=microsoft.com@python.org] On Behalf Of Donald Stufft Sent: Thursday, 3 October 2013 0712 To: DistUtils mailing list Subject: [Distutils] Test Windows Installers
Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi
Let me know?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Donald Stufft wrote:
On Oct 3, 2013, at 5:59 PM, Steve Dower
wrote: I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against:
WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64
With Python 2.7.5, 3.2.3 and 3.3.2, x86 and x64 for each. (It helps to have a bit of practice with large test matrices, convenient access to clean VMs for lots of operating systems, and a couple of internal automation tools :) )
One issue I noticed is that if you've previously installed pip from source and it's in easy-install.pth, the version from the MSI won't be used when it is installed. The same applies to setuptools. (I used setuptools 0.9.8 and pip 1.3.1 for testing this.)
What do you mean for this? That if you already have pip 1.3.1 installed and you install from the MSI when it's over the installed version is still 1.3.1?
Both versions are installed, but `python -m pip` is going to select 1.3.1. (I didn't actually try Scripts\pip.exe, but since that's using pkg_resources I assume it will get the right one.) I did the initial installs with the package setup.py files which produced a .egg file for setuptools and a .egg folder for pip. I'm not actually sure whether there's anything you could do about this from an installer... Cheers, Steve
In general there don't seem to be any other problems with it. I've noted some
possible issues below, but since I don't know how much control you have over these, please don't take it personally if I'm pointing out things that cannot be changed.
- the default value for specifying a manual path ("D:\PythonX") should
probably be "C:\PythonXY" where XY is the version the installer is targeting.
Hmm, I'll see what I can do about this, I'm reusing routines from distutils to handle this but I may have some level of control over that.
- 64-bit versions of Python installed for all users are not detected. Are you planning a 64-bit version of this installer? (Specifying the path manually worked fine.)
Yea that was pointed out to me, I'll probably make 64bit installers since I don't think a 32bit installer can detect the 64bit versions.
- the RemoveFile table is incorrect for Python 3.x - there are no references
to __pycache__ folders, only to .pyc and .pyo files in the same folder as their .py counterpart. As a result, uninstall is not clean for Python 3.2 and 3.3. In particular, Python 3.3 will show this (instead of "No module named pip"):
This is going to be an issue with distutils again, I'll see if I can control it but it'd probably be a good idea to get this fixed in distutils too.
C:\ >C:\Python33\python.exe -m pip Traceback (most recent call last): File "C:\Python33\lib\runpy.py", line 140, in _run_module_as_main mod_name, loader, code, fname = _get_module_details(mod_name) File "C:\Python33\lib\runpy.py", line 105, in _get_module_details if loader.is_package(mod_name): AttributeError: 'NamespaceLoader' object has no attribute 'is_package'
- choosing between 'All Users' and 'Just For Me' in the pip installer didn't
seem to affect the install location.
AFAIK distutils added that, no idea what it does or means. I'll see if I can remove it.
- uninstalling Python before pip worked fine. (No problem here, just letting you know that I tried it :) ) - selecting both install options (Python from registry/custom path) and specifying the same path worked fine
Caveats: - all machines were clean OS installs + Python from python.org. I didn't try installing Python from other sources - I only tested upgrading pip with the installer on Windows 8, but I'm confident it will behave the same on all other platforms
All up, it looks great, and it's going to make things much easier for Windows
users. Thanks for doing this.
Cheers, Steve
-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+steve.dower=microsoft.com@python.org] On Behalf Of Donald Stufft Sent: Thursday, 3 October 2013 0712 To: DistUtils mailing list Subject: [Distutils] Test Windows Installers
Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27. msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32. msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33. msi
Let me know?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Oct 3, 2013, at 6:20 PM, Steve Dower
Donald Stufft wrote:
On Oct 3, 2013, at 5:59 PM, Steve Dower
wrote: I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against:
WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64
With Python 2.7.5, 3.2.3 and 3.3.2, x86 and x64 for each. (It helps to have a bit of practice with large test matrices, convenient access to clean VMs for lots of operating systems, and a couple of internal automation tools :) )
One issue I noticed is that if you've previously installed pip from source and it's in easy-install.pth, the version from the MSI won't be used when it is installed. The same applies to setuptools. (I used setuptools 0.9.8 and pip 1.3.1 for testing this.)
What do you mean for this? That if you already have pip 1.3.1 installed and you install from the MSI when it's over the installed version is still 1.3.1?
Both versions are installed, but `python -m pip` is going to select 1.3.1. (I didn't actually try Scripts\pip.exe, but since that's using pkg_resources I assume it will get the right one.)
I did the initial installs with the package setup.py files which produced a .egg file for setuptools and a .egg folder for pip. I'm not actually sure whether there's anything you could do about this from an installer…
Ahhh, Ok that makes sense. Yea I'm not sure what I can do about that. I'll have to think it over and see if I can come up with anything.
Cheers, Steve
In general there don't seem to be any other problems with it. I've noted some
possible issues below, but since I don't know how much control you have over these, please don't take it personally if I'm pointing out things that cannot be changed.
- the default value for specifying a manual path ("D:\PythonX") should
probably be "C:\PythonXY" where XY is the version the installer is targeting.
Hmm, I'll see what I can do about this, I'm reusing routines from distutils to handle this but I may have some level of control over that.
- 64-bit versions of Python installed for all users are not detected. Are you planning a 64-bit version of this installer? (Specifying the path manually worked fine.)
Yea that was pointed out to me, I'll probably make 64bit installers since I don't think a 32bit installer can detect the 64bit versions.
- the RemoveFile table is incorrect for Python 3.x - there are no references
to __pycache__ folders, only to .pyc and .pyo files in the same folder as their .py counterpart. As a result, uninstall is not clean for Python 3.2 and 3.3. In particular, Python 3.3 will show this (instead of "No module named pip"):
This is going to be an issue with distutils again, I'll see if I can control it but it'd probably be a good idea to get this fixed in distutils too.
C:\ >C:\Python33\python.exe -m pip Traceback (most recent call last): File "C:\Python33\lib\runpy.py", line 140, in _run_module_as_main mod_name, loader, code, fname = _get_module_details(mod_name) File "C:\Python33\lib\runpy.py", line 105, in _get_module_details if loader.is_package(mod_name): AttributeError: 'NamespaceLoader' object has no attribute 'is_package'
- choosing between 'All Users' and 'Just For Me' in the pip installer didn't
seem to affect the install location.
AFAIK distutils added that, no idea what it does or means. I'll see if I can remove it.
- uninstalling Python before pip worked fine. (No problem here, just letting you know that I tried it :) ) - selecting both install options (Python from registry/custom path) and specifying the same path worked fine
Caveats: - all machines were clean OS installs + Python from python.org. I didn't try installing Python from other sources - I only tested upgrading pip with the installer on Windows 8, but I'm confident it will behave the same on all other platforms
All up, it looks great, and it's going to make things much easier for Windows
users. Thanks for doing this.
Cheers, Steve
-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+steve.dower=microsoft.com@python.org] On Behalf Of Donald Stufft Sent: Thursday, 3 October 2013 0712 To: DistUtils mailing list Subject: [Distutils] Test Windows Installers
Anyone who has a windows machine mind testing some installers for me?
These should install pip and setuptools:
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27. msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32. msi
https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33. msi
Let me know?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Bleh, and of course I find an issue, the generated scripts have a hardcoded shebang, will need to figure out how to regenerate those during the install process I guess. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
participants (5)
-
Donald Stufft
-
Nick Coghlan
-
Steve Dower
-
Tim Golden
-
Vladimir Diaz