Re: [XML-SIG] Problem installing PyXMLv0.6.6
In a message to the XML-SIG, Thomas Heller writes:
From: "Göran Rolfsson" Goran.Rolfsson@reachin.se
Hi! I first tried the exe-version ( I have NT), but it wants me to select the Python installation to use, without showing me any to choose among, and without the possibility to specify a path. And yes, I have Python installed on my machine (actually in several versions).
Göran,
the exe-version is probably built with distutils bdist_wininst command. This looks in the registry under HKEY_LOCAL_MACHINE\Software\Python\PythonCore\x.y\InstallPath to find the location where Pythin is installed. (x.y is the required version 2.0, 2.1, whatever). This registry key is created by the installer when you install Python itself. If you compiled it from source, it will not be present.
Would it make sense to enhance the search strategy a bit? I'll propose the following strawman:
1. Start with what it already does. 2. Search the PATH for "python.exe" 3. Ask the user to specify exactly where is should go.
I don't know how much work this would be, but it might help people that do build from source, or who use an alternate installer that doesn't upt things in the registry (PythonWare, for instance).
-Fred
From: "Fred L. Drake, Jr." fdrake@acm.org
In a message to the XML-SIG, Thomas Heller writes:
From: "Göran Rolfsson" Goran.Rolfsson@reachin.se
Hi! I first tried the exe-version ( I have NT), but it wants me to select the Python installation to use, without showing me any to choose among, and without the possibility to specify a path. And yes, I have Python installed on my machine (actually in several versions).
Göran,
the exe-version is probably built with distutils bdist_wininst command. This looks in the registry under HKEY_LOCAL_MACHINE\Software\Python\PythonCore\x.y\InstallPath to find the location where Pythin is installed. (x.y is the required version 2.0, 2.1, whatever). This registry key is created by the installer when you install Python itself. If you compiled it from source, it will not be present.
Would it make sense to enhance the search strategy a bit? I'll propose the following strawman:
1. Start with what it already does. 2. Search the PATH for "python.exe" 3. Ask the user to specify exactly where is should go.
Actually it's a little more complicated than this. It does not only need the directory where python.exe is found, it must also make sure this is the correct python version. How can you find out from python.exe?
I don't know how much work this would be, but it might help people that do build from source, or who use an alternate installer that doesn't upt things in the registry (PythonWare, for instance).
It's strange that nobody has complained so far... Maybe people compiling python from source also compile extensions from source? And everyone else either run ActiveState Python or PythonLabs?
Thomas
Thomas Heller writes:
Actually it's a little more complicated than this. It does not only need the directory where python.exe is found, it must also make sure this is the correct python version. How can you find out from python.exe?
Good question; I have no idea how to extract that information.
It's strange that nobody has complained so far... Maybe people compiling python from source also compile extensions from source? And everyone else either run ActiveState Python or PythonLabs?
Part of it may be that distutils-based installers for Windows are still fairly new, and they're only now being used on enough installation flavors to turn up the more complicated conditions. Or maybe it just doesn't matter. ;-)
-Fred
From: "Fred L. Drake, Jr." fdrake@acm.org
Thomas Heller writes:
Actually it's a little more complicated than this. It does not only need the directory where python.exe is found, it must also make sure this is the correct python version. How can you find out from python.exe?
Good question; I have no idea how to extract that information.
There is a Windows api to find out which pythonxx.dll python.exe binds to, so it should be possible.
Thomas
Thomas Heller writes:
There is a Windows api to find out which pythonxx.dll python.exe binds to, so it should be possible.
Cool! So there is hope for people who build from source but don't or can't build the installer. (Wise was generous in giving us a copy of their current installer builder, but it was only one license.)
-Fred
From: "Fred L. Drake, Jr." fdrake@acm.org
Thomas Heller writes:
There is a Windows api to find out which pythonxx.dll python.exe binds to, so it should be possible.
Cool! So there is hope for people who build from source but don't or can't build the installer. (Wise was generous in giving us a copy of their current installer builder, but it was only one license.)
I have implemented most of this.
The user can browse for other python.exe files, and the installer determines the dll which this exe loads.
The final problem is that I'm not able to figure out sys.prefix for this executable.
I tried to dynamically embed this dll, and retrieve sys.prefix. Normally this is empty. If I do not set PYTHONHOME, sys.prefix is wrong (the path to the installer executable). If I do set PYTHONHOME to the actual python.exe, sys.prefix is also wrong (path to the python.exe). In case I've compiled my python from source, the path to the exe is ...\src\PCBUILD\python.exe, and sys.prefix is set to ...\src\PYBUILD while it should be '...\src'. sys.path seems to be set correctly.
The only possibility I see at the moment is to import the os module, retrieve the path from it (which is <prefix>/lib/os.py), and determine the prefix from it. Aren't there any other solutions?
Thomas
participants (2)
-
Fred L. Drake, Jr. -
Thomas Heller