[issue21427] installer not working
Peter Santoro added the comment: I believe I may have hit a related issue yesterday. I'm using Python 3.3.5 (32 and 64 bit) and 3.4.1 (32 and 64 bit) releases all on the same Windows 7SP1/64bit PC (patched with latest MS updates). The Tkinter applications that I wrote and have been using with 3.x for a while now stopped working sometime after installing 3.4.1 - I only noticed this behavior yesterday. All the Tkinter apps run fine as .py files (but with an associated console window); however, they no longer run as .pyw files. Instead, they silently fail. I checked my file associations/types and I believe they are correct. The py.exe and pyw.exe files are in the Windows directory. None of my colleagues have this issue, but they only have one Python installation (3.4.1 64bit). My users also only have one Python version installed (3.3.5 or 3.4.1) and they are not experiencing this issue. I did search for a empty file on the path with the same name as the python script that I was trying to execute, as this will lead to silent failures - but I found none. I also tried using the Python Windows installer repair facility on the Python 3.4.1 64bit install, but that didn't help. I then uninstalled and reinstalled my Python 3.4.1 64bit release, but that didn't help either. I did notice that the py.exe and pyw.exe files in my Windows directory were not identical to a colleague's Python 3.4.1 64bit PC. I then ran pyw.exe via windbg (e.g. windbg pyw.exe -3.4 irtool.pyw, windbg pyw.exe -3.4-32 irtool.pyw) to see if there were obvious errors. I discovered that my pyw.exe silently fails whenever it is instructed to use the 3.4.1 release. However, when I specified Python 3.3.5 (pyw.exe -3.3 or -3.3-32) my Tkinter applications ran fine and as expected, without an associated console window. I'm reasonably certain that I did not intentionally modify the py.exe and pyw.exe files in my Windows directory. Also, all my scripts start with the following: #!/usr/bin/python3 Unfortunately, I'm not able to uninstall 3.3.5, until we upgrade all users to 3.4.x (probably shortly after 3.4.2 is released). -- nosy: +pe...@psantoro.net ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: problem is solved observation - installer problem only occurred on win7 32 bit with prior python installation (my working system) - When repeating the installer problem I noticed that a window was opened very shortly with python.exe running. An error message from this call resulted in the exit process of the installer - the window popped up only for about 1second. A was reading (taking a video) that it was complaining about an error in numpy when calling imp.py in /python33/lib (the old installation, something wrong with libtool, bootstrap) - I removed step by step all installed libraries, but the error still appeared - I removed the prior python 3.3.5 installation completely, now the installer worked - when opening the window with python, it was downloading something like setuptools (not absolutely sure about the name) - a test with nose 1.3.3, numpy 1.8.1, scipy 0.14.0 (all from Gohlkes web site) went ok. - unfortunately, the error message with the registry was not reflecting the problem Hence, the solution is to remove the prior installation of python. That was not necessary in older versions and not necessary for win7 64 bit: strange. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: the installer went 2/3 through the process and was installing already something in the default dir c:\Python34 Then after a small pause the error message was shown and the installer removed all the files leaving an empty ..\lib in the default dir The behavior is quite reproducible with *.msi for python 3.4.0 and 3.4.1 Its independent on whether the prior installation dir is removed or not It is not an issue of the antivirus software (I am running win7 prof sp1 with the latest updates) It is not clear from the process but I am convinced this happens when the installer tries to register python in the registry It never happened with any of the prior python 3.0 to 3.3.5 For the own compiled version I can run python.exe of the 3.4.1 sources but haven tested whether its executing anything fine. So it does not seem to be a problem of python3.4.x on 32bit -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Zachary Ware added the comment: Nosy-ing the Windows installer experts; I haven't had any problems with this and am not familiar with the MSI library or tool. -- nosy: +loewis, steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Mark Lawrence added the comment: FWIW I've never had any installation problems involving py.exe. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Steve Dower added the comment: eryksun's analysis is correct. If the component is marked 64-bit then it will not install on a 32-bit OS. This needs to be switched for the 32-bit installer. (I also don't see why you'd want to set the 64-bit SharedDLLs key for a 32-bit DLL. Is there some reason we need to do this?) The default download button currently gets the 32-bit version of 3.4.1, which is the correct default even for people with a 64-bit system. Up until you realize that your script legitimately needs more than 2GB of memory, nobody needs 64-bit Python (barring external library requirements). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: not sure what you mean: the installer for 64 bit is working fine the installer for 32 bit is not working - this is true also for the new version 3.4.1 for those who may try: compiling is tricky with VC2010 pro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Terry J. Reedy added the comment: I think what Steve meant is that *if* the 32-bit installer is working right, then it should be the default because it would then work for everyone, while the 64-bit installer cannot possibly work for people with 32-bit windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Martin v. Löwis added the comment: Here is the rationale: 1. py.exe is a 32-bit binary installed into C:\windows, see PEP 397. It's in C:\windows so that it will be on the path for both 32-bit and 64-bit processes. 2. py.exe is installed by multiple installers (both 32-bit and 64-bit, and multiple versions of Python) 3. to do proper reference counting of the installations, the SharedDLLRefcount component flag is enabled for the py.exe component. As a consequence, py.exe will be removed when the last Python installation is uninstalled from the system. 4. there are two different reference counters for a file on Windows: a 32-bit reference counter and a 64 bit reference counter. A 64-bit installer would manipulate the 64-bit counter, and a 32-bit installer would manipulate the 32-bit counter. 5. by default, this would lead to py.exe disappearing after this sequence of installation steps: * install 32-bit 3.3 * install 64-bit 3.4 * uninstall 64-bit 3.4 The 32-bit reference counter would still be 1, but the 64-bit uninstallation would only look at the 64-bit counter, removing the file 6. to prevent that, the component is marked as 64-bit even for the 32-bit installer, to manipulate the 64-bit reference counter. The code contains a comment # XXX does this still allow to install the component on a 32-bit system? I never got to test this out of lack of a 32-bit Windows installation, apparently, it doesn't work. As a work-around, the 32-bit installer could include an additional component installing py.exe, which would be a 32-bit component and be selected if the host system is 32-bit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Zachary Ware added the comment: Martin v. Löwis wrote: I never got to test this out of lack of a 32-bit Windows installation, apparently, it doesn't work. It does work on my 32-bit machine, though; I have had no issues installing 32-bit Python 3.3 or 3.4 on 32-bit Windows 7 Pro. If there's anything in particular you would like me to test or check, let me know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Steve Dower added the comment: That reasoning makes sense. I don't see any other way to achieve the same thing without requiring a newer version of Windows Installer on the machine (msidbComponentAttributesDisableRegistryReflection requires 4.0). Having a second component for 32-bit OS may be okay. I don't recall whether the component ID or the key path is used for shared DLLs - if it's the ID then you won't be able to do this, but I believe it uses the key path throughout (obviously the OS uses the path, but Windows Installer may not). The 3.4.1 installer worked fine for me on a 32-bit OS, but it doesn't seem to have added py.exe into the SharedDLLs key (python34.dll is there). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Martin v. Löwis added the comment: Zachary: It shouldn't work for you, given this report. Please run msiexec /i python msi file /l*v py.log and attach the (possibly compressed) py.log. Verify that it actually did install py.exe into c:\windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Zachary Ware added the comment:
Here's the log, and some notes:
Starting state:
- Python 3.3.5 installed to P:\Python33
- Python 3.4.1 installed to P:\Python34
- py[w].exe present in C:\Windows
State after Python 3.4.1 uninstalled by python-3.4.1.msi (and manually removed
P:\Python34 which still contained some debris in Lib and Scripts):
- Python 3.3.5 still installed
- Python 3.4.1 uninstalled
- py[w].exe no longer present in C:\Windows
msiexec /i python-3.4.1.msi /l*v py.log
- Installed for all users
- Destination set to P:\Python34
- Components left at default (all selected except 'Add python.exe to Path')
- Install completed successfully
State afterward:
- Python 3.3.5 still installed
- Python 3.4.1 properly installed in P:\Python34
- py[w].exe now present in C:\Windows
Picking through the log, I find that I did actually get the error the OP noted;
it just doesn't seem to matter:
MSI (s) (34:04) [14:27:17:664]: Executing op:
ComponentRegister(ComponentId={81B1269C-979C-404A-8E3D-D297B7C38622},KeyPath=C:\Windows\py.exe,State=3,,Disk=1,SharedDllRefCount=1,BinaryType=1)
1: {DF32BB9E-3ED8-36B5-A649-E8C845C5F3A2} 2:
{81B1269C-979C-404A-8E3D-D297B7C38622} 3: C:\Windows\py.exe
MSI (s) (34:04) [14:27:17:665]: Error: cannot register 64 bit component
{81B1269C-979C-404A-8E3D-D297B7C38622} on 32 bit system. KeyPath:
C:\Windows\py.exe
MSI (s) (34:04) [14:27:17:665]: GetSharedDLLKey called with invalid
ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:665]: GetSharedDLLKey called with invalid
ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:666]: Executing op:
ComponentRegister(ComponentId={C170DD8A-2030-4226-A15D-94E881D68233},KeyPath=C:\Windows\pyw.exe,State=3,,Disk=1,SharedDllRefCount=1,BinaryType=1)
1: {DF32BB9E-3ED8-36B5-A649-E8C845C5F3A2} 2:
{C170DD8A-2030-4226-A15D-94E881D68233} 3: C:\Windows\pyw.exe
MSI (s) (34:04) [14:27:17:667]: Error: cannot register 64 bit component
{C170DD8A-2030-4226-A15D-94E881D68233} on 32 bit system. KeyPath:
C:\Windows\pyw.exe
MSI (s) (34:04) [14:27:17:668]: GetSharedDLLKey called with invalid
ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:668]: GetSharedDLLKey called with invalid
ibtBinaryType argument!
...
MSI (s) (34:04) [14:27:19:599]: Executing op:
SetTargetFolder(Folder=C:\Windows\)
MSI (s) (34:04) [14:27:19:599]: Executing op: SetSourceFolder(Folder=1\)
MSI (s) (34:04) [14:27:19:599]: Executing op:
FileCopy(SourceName=PY.EXE|py.exe,SourceCabKey=py.exe,DestName=py.exe,Attributes=512,FileSize=102400,PerTick=65536,,VerifyMedia=1,CheckCRC=0,Version=3.4.1150.1013,Language=2057,InstallMode=58982400,,,)
MSI (s) (34:04) [14:27:19:600]: File: C:\Windows\py.exe;To be
installed;Won't patch;No existing file
MSI (s) (34:04) [14:27:19:600]: Source for file 'py.exe' is compressed
InstallFiles: File: py.exe, Directory: C:\Windows\, Size: 102400
MSI (s) (34:04) [14:27:19:606]: Executing op:
FileCopy(SourceName=PYW.EXE|pyw.exe,SourceCabKey=pyw.exe,DestName=pyw.exe,Attributes=512,FileSize=102912,PerTick=65536,,VerifyMedia=1,CheckCRC=0,Version=3.4.1150.1013,Language=2057,InstallMode=58982400,,,)
MSI (s) (34:04) [14:27:19:606]: File: C:\Windows\pyw.exe; To be
installed;Won't patch;No existing file
MSI (s) (34:04) [14:27:19:606]: Source for file 'pyw.exe' is compressed
InstallFiles: File: pyw.exe, Directory: C:\Windows\, Size: 102912
--
Added file: http://bugs.python.org/file35473/py.log.bz2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21427
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Martin v. Löwis added the comment: That the removal of 3.4 removes py.exe despite 3.3 still being installed is easy to explain: the registration of the reference counter failed, hence the file was not reference counted, and the first removal decided to remove it (there being no reference counter). I can't explain why cannot register 64-bit component is fatal on some systems and not on others. Steve? Uwe: where exactly did you get the message in your original report? What steps did you do, and where did the message show up? Did the installation perhaps complete despite this error? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Terry J. Reedy added the comment: I compile 32 bit debug binaries from repository with the free VC++ express 2010. I presume the 'install' option works. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: I guess this is merely describing the problem and not the solution? (by the way I had no difficulties with the 64bit version on a 64bit win7 system) Would it be possible to produce the binairies myself using the mingw compiler? The readme says visual c++ is required. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
New submission from Uwe:
Installer fails to install 3.4 on win7 32 bit
Error: cannot register 64 bit component {BE22BD81-ECE5-45BD-83B8-84BA45846A2D}
on 32 bit system. KeyPath: C:\Windows\py.exe
--
messages: 217878
nosy: ellipso
priority: normal
severity: normal
status: open
title: installer not working
type: crash
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21427
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Ned Deily added the comment: Did you try using the 32-bit (x86) installer from https://www.python.org/downloads/release/python-340/ ? Unfortunately, I believe the default download button currently only downloads the 64-bit version. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: Of course, only official sources the file is named python-3.4.0.msi and 23,924KB the name is similar to that of earlier versions which worked fine So I am not sure, whether it is 32 or 64bit maybe it would be a good idea to use two different names such as x86 and x64? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Ned Deily added the comment: There are two different names: the 64-bit installer is python-3.4.0.amd64.msi. But I see now that the error refers to py.exe, which I believe is the Python launcher. I've nosyed the Windows experts. -- nosy: +tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
eryksun added the comment:
This is the first time I've used msilib, but it does appear that the component
is marked as 64-bit:
import msilib
msidbComponentAttributes64bit = 256
sql = (SELECT ComponentId,Attributes FROM Component
...WHERE Component='launcher')
db = msilib.OpenDatabase('python-3.4.0.msi', msilib.MSIDBOPEN_READONLY)
v = db.OpenView(sql)
v.Execute(None)
r = v.Fetch()
r.GetString(1)
'{BE22BD81-ECE5-45BD-83B8-84BA45846A2D}'
attr = r.GetInteger(2)
attr
264
attr msidbComponentAttributes64bit
256
As it should be according to Tools/msi/msi.py:
http://hg.python.org/cpython/file/04f714765c13/Tools/msi/msi.py#l990
Here's the comment regarding this:
# msidbComponentAttributes64bit = 256; this disables registry redirection
# to allow setting the SharedDLLs key in the 64-bit portion even for a
# 32-bit installer.
# XXX does this still allow to install the component on a 32-bit system?
# Pick up 32-bit binary always
For reference, the Component table:
http://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21427
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
