New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distutils-based installer does not detect 64bit versions of Python #51041
Comments
An installer for source-only modules created using distutils Expected behaviour: |
Unfortunately, I don't think this is possible. When creating the At least, can't think of an easy way to solve it. |
This prevents numerous packages from installing correctly including the It seems to be looking for it in: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\InstallPath] .. rather than the: .. that the python installer puts in the registry. This is related to the conversation in this thread: http://www.mail-archive.com/distutils-sig@python.org/msg10512.html And to quote from http://bugs.python.org/setuptools/issue2 : "The issue is with the .exe header used by the bdist_wininst command; |
Carwyn: those packages just need to create two versions of their |
It is possible to create combined x86 and x64 msi files and in fact it |
sorin: can you provide a patch? |
ISTM there may be two ways to fix this problem; one was to change the The other way, which has more probability of working, is for the 64-bit (This might also require an install-time 64/32 compatibility check being |
32bit apps can query the 64bit registry, using the appropriate security and access rights options such as KEY_WOW64_64KEY (0x0100). Similarly KEY_WOW64_32KEY can be used for 64bit apps to read/write the 32bit registry without having to have knowledge of how the Wow6432Nodes are arranged . These mean that a 64bit aware app, whether compiled as 64 or 32 bits, can access the alternative view of the registry. http://msdn.microsoft.com/en-us/library/ms724897(VS.85).aspx For example if you have both 64 and 32 bit copies of Python installed then a Python app running under the 32bit copy of Python can query the location of the 64bit copy of Python using code like: C code can do similarly. |
One issue to consider is pre/post-install actions. bdist_wininst loads pythonxy.dll from the target system, which would fail if it is a 32-bit installer process that tries to load a 64-bit python DLL. |
Does anyone know of any workaround, for now? |
Removing 2.6 which only gets security fixes now. |
you can add InstallPath key with the corresponding value at [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\] |
There are many updated installers, for many libs for those of us using 64bit windows 7. |
Could you please change the priority of this Issue to 'High' as this problem is a big annoyance for all Windows 64bits users which is a rather large niche of users (a niche getting larger and larger everyday), don't you think ? |
I'll leave priority setting to tarek, but it doesn't look to me like raising the priority is going to make any difference, since it doesn't sound from reading the ticket like anyone has found a solution yet (other than offering 64bit installers). |
Yeah I agree. Until we get a solution + patch the priority here does not really matter. |
I'm not certain that I agree with the argument used to justify keeping this as a 'normal' priority issue. Apparently, since it doesn't effect the entire python community and being as there is no readily available solution, the decision is to treat it as a minor problem. Were one to apply the same logic to, what say, epidemiology, then I suppose the lack of a vaccine for HIV would not be a particularly pressing issue either. If priority escalation is out of the question, can we at least have an update? After three years of workarounds, I'm beginning to suspect that the idea is to wait until the effected packages become deprecated and then declare 'solved!'. |
Without a patch or a solution, the priority doesn't really matter (like Tarek said in msg127630). If anyone is actively working on this feel free to say otherwise, but I see no status to update. |
It's not out of the question - it's just that setting the priority on Instead, there are two forms of escalation available:
|
This bug is a really annoying one, any chance it will be fixed in 2.7? It's really a matter when you want to deploy a program using distutils (my case), because you cannot really require your clients to edit the registry themselves :/ Is there any problem with just adding the x32 compatibility path entry to the python x64 .msi? It's a very easy fix that shouldn't cause any harm. |
I would like to investigate this issue, but I need more information regarding the bug and the expected behavior. Is this specifically that an x64 windows python that generates a bdist (msi output) runs and can't find the x64 interpreter because of syswow registry redirection? That is, packaging should be able to find the interpreter bitness that generated the msi in the first place (and no-other bitness)? There are python sprints this week at PyCon, but I cannot attend them. Clarifying the expected behavior this week will help me write tests and investigate/fix (if it is in my ability). |
Erik: the issue is about bdist_wininst, not bdist_msi (bdist_msi has a similar issue, but it is entirely different in its causes and potential resolution, and shall not be discussed here). The code to find the installations is in PC/bdist_wininst/install.c:GetPythonVersions. The code to run the installscript is in run_installscript. |
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: