Just noticed a checkin talking about the Windows Installer builder. I hope to find some time soon to take a look at that, since we now require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I recall talking with Mark about it and he said it would take some time to fix the build process. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
[Sidnei da Silva]
Just noticed a checkin talking about the Windows Installer builder. I hope to find some time soon to take a look at that, since we now require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I recall talking with Mark about it and he said it would take some time to fix the build process.
I just asked Andreas (off-list) what his Windows plans were for 2.9 -- for various reasons I assumed someone else was already looking at this, but that assumption may be wrong (and given the lack of relevant checkins recently, almost certainly wrong <frown>). WRT Python 2.4, I never found a sane way to just _extract_ files from an .msi installer, so that part of the build process is dead meat now. In other "bundle everything" Windows installers at Zope Corp (such as for ZRS), I copy Python .pyd. .dll and .exe files from my own Python 2.4.2 installation instead. These binary files are all the build-Zope-installer process really needs from the Python Windows installer; the rest (like .py and .h files) can be taken from a Python tarball. You can avoid wrestling with .msi entirely this way. Possible headache: Python 2.4.2 requires msvcr71.dll, which is a Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the C runtime for VC 7.1), and one for which the redistribution conditions are unclear (at least to me). You can't assume that all Windows boxes already have this DLL. Another: I have no idea how the new zpkg-based build process will work with a Zope2-style installer. A Zope3-style installer is different in many ways (it's a "plain" distutils-based installer, and requires that the end user get and install Python & pywin32 first). Plan on pain-time here.
On Tue, Dec 06, 2005 at 12:35:49PM -0500, Tim Peters wrote: | [Sidnei da Silva] | > Just noticed a checkin talking about the Windows Installer builder. I | > hope to find some time soon to take a look at that, since we now | > require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I | > recall talking with Mark about it and he said it would take some time | > to fix the build process. | | I just asked Andreas (off-list) what his Windows plans were for 2.9 -- | for various reasons I assumed someone else was already looking at | this, but that assumption may be wrong (and given the lack of relevant | checkins recently, almost certainly wrong <frown>). | | WRT Python 2.4, I never found a sane way to just _extract_ files from | an .msi installer, so that part of the build process is dead meat now. | In other "bundle everything" Windows installers at Zope Corp (such as | for ZRS), I copy Python .pyd. .dll and .exe files from my own Python | 2.4.2 installation instead. These binary files are all the | build-Zope-installer process really needs from the Python Windows | installer; the rest (like .py and .h files) can be taken from a Python | tarball. You can avoid wrestling with .msi entirely this way. Just came to the same conclusion a few minutes ago. | Possible headache: Python 2.4.2 requires msvcr71.dll, which is a | Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the | C runtime for VC 7.1), and one for which the redistribution conditions | are unclear (at least to me). You can't assume that all Windows boxes | already have this DLL. Indeed. From reading around, seems like the saner thing is to make it a bold warning in the installer that the said dll is required instead of shipping it. | Another: I have no idea how the new zpkg-based build process will | work with a Zope2-style installer. A Zope3-style installer is | different in many ways (it's a "plain" distutils-based installer, and | requires that the end user get and install Python & pywin32 first). | Plan on pain-time here. That's something I can play with :) -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
... [Tim]
| Possible headache: Python 2.4.2 requires msvcr71.dll, which is a | Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the | C runtime for VC 7.1), and one for which the redistribution conditions | are unclear (at least to me). You can't assume that all Windows boxes | already have this DLL.
[Sidnei]
Indeed. From reading around, seems like the saner thing is to make it a bold warning in the installer that the said dll is required instead of shipping it.
If you go the Zope3-route, it becomes a non-issue: the Windows Python installer will install msvcr71.dll if needed. Redistribution there isn't a problem because the PSF builds the binaries using a duly licensed Microsoft compiler. It's much fuzzier for "derivative works" (do the PSF's redistribution rights pass through to them? ask two lawyers, get four answers). Zope Corp could presumably invoke the same rights because parts of Zope are compiled with a legitimately licensed VC 7.1 -- but that might depend on who does the compliing.
| Another: I have no idea how the new zpkg-based build process will | work with a Zope2-style installer. A Zope3-style installer is | different in many ways (it's a "plain" distutils-based installer, and | requires that the end user get and install Python & pywin32 first). | Plan on pain-time here.
That's something I can play with :)
Feedback from users hasn't been exactly glowing, but it's much easier to build an installer that way (no externals, no makefiles, no Cygwin involved, ...). Here's how it's done for Zope3; I don't know / can't guess what would need to change for Zope2: <http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease>
On Tue, Dec 06, 2005 at 01:22:23PM -0500, Tim Peters wrote: | [Sidnei] | > Indeed. From reading around, seems like the saner thing is to make it | > a bold warning in the installer that the said dll is required instead | > of shipping it. | | [Tim] | If you go the Zope3-route, it becomes a non-issue: the Windows Python | installer will install msvcr71.dll if needed. Redistribution there | isn't a problem because the PSF builds the binaries using a duly | licensed Microsoft compiler. It's much fuzzier for "derivative works" | (do the PSF's redistribution rights pass through to them? ask two | lawyers, get four answers). Zope Corp could presumably invoke the | same rights because parts of Zope are compiled with a legitimately | licensed VC 7.1 -- but that might depend on who does the compliing. I've discussed with Mark a bit, and we came to a couple conclusions. Looks like the MSI installer has some support for 'multiple instance transforms' (not sure that's the term used in MS docs), but apparently that requires some build-time tweaking to be enabled. Another idea is to include the full Python2.4 installer, make the installer detect a existing Python2.4 install and if not existing then run the python installer silently. | [Tim] | >| Another: I have no idea how the new zpkg-based build process will | >| work with a Zope2-style installer. A Zope3-style installer is | >| different in many ways (it's a "plain" distutils-based installer, and | >| requires that the end user get and install Python & pywin32 first). | >| Plan on pain-time here. | | > That's something I can play with :) | | Feedback from users hasn't been exactly glowing, but it's much easier | to build an installer that way (no externals, no makefiles, no Cygwin | involved, ...). Here's how it's done for Zope3; I don't know / can't | guess what would need to change for Zope2: | | <http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease> Simplifying a lot what the existing Zope 2 installer does, it basically creates a 'software home', a default 'instance home' and registers the services. All but the first part is done manually for Zope 3, so I can see the lack of glow there. Supposing there is a existing python installation, how difficult is it to get a distutils-based windows installer to be extracted to a random directory outside site-packages? My guess is that it's basically unzip it. If that's the case, we can simplify the Zope 2 inno installer to: 1. include a distutils-based windows installer for the Zope 2 source 2. include some setup scripts Then on installation 1. find or install according python 2. unpack the distutils-based windows installer into Program Files\Zope 3. create a default 'instance home', pointing to the installed python 4. register the services Steps 2-4 are reasonably simple to me, the tricky one is 1. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
... [Sidnei da Silva]
Simplifying a lot what the existing Zope 2 installer does, it basically creates a 'software home', a default 'instance home' and registers the services. All but the first part is done manually for Zope 3, so I can see the lack of glow there.
There's also that Zope2 sticks Python inside of Zope, but Zope3 sticks Zope inside of Python. A consequence is that you can't install more than one instance of Zope3 under a single Windows account, but can install any number of Zope2s. In the other direction, it's always a puzzle for Zope2 Windows users to figure out how to give their Zope access to packages installed in their (own, separate) Python. For Zope3 that's a no-brainer.
Supposing there is a existing python installation, how difficult is it to get a distutils-based windows installer to be extracted to a random directory outside site-packages?
distutils has no support for that.
My guess is that it's basically unzip it.
What are you trying to accomplish? (I know you're trying to push code into some directory other than under Lib/site-packages, but I don't know which code or why.)
If that's the case, we can simplify the Zope 2 inno installer to:
1. include a distutils-based windows installer for the Zope 2 source 2. include some setup scripts
Then on installation
1. find or install according python
Note that Zope also needs pywin32 to be installed.
2. unpack the distutils-based windows installer into Program Files\Zope
OK, so you're trying to preserve that ... what? You're neither sticking Python inside Zope nor Zope inside Python? BTW, _how_ do you unpack this at install time? You can't, for example, assume that a Windows box has any unzip utility (let alone some specific one). So this part would probably be simpler if you point Inno at a Zope tree and let _it_ package it and unpack it. Maybe the way to get such a tree is to build a distutils installer for Zope and run it on your own box, pointing Inno at the tree it creates, then throw the distutils installer away <0.3 wink>.
3. create a default 'instance home', pointing to the installed python
An instance home _certainly_ doesn't belong inside the user's Python -- but maybe I don't know what you mean by these words (I'm probably misreading "pointing to"). It should be possible to create any number of distinct instance homes.
4. register the services
Steps 2-4 are reasonably simple to me, the tricky one is 1.
Maybe somone will hit me for this ;-), but we have Inno code for #1 in one of our other installers. It goes like this: [Code] var // Path to the user's Python installation, found from the registry. // Procedure SetPythonInstallPath deduces this. gPythonInstallPath: String; function InitializeSetup(): boolean; begin gPythonInstallPath := ''; // don't know yet Result := True; end; ... // Look up Python's install path in the registry. Use HKCU first, because // a "user-only" instance is supposed to take precedence. If no Python is // installed, this will leave gPythonInstallPath as an empty string. procedure SetPythonInstallPath(); begin RegQueryStringValue(HKCU, 'Software\Python\PythonCore\2.4\InstallPath', '', gPythonInstallPath); if gPythonInstallPath = '' then // not in HKCU, so try HKLM RegQueryStringValue(HKLM, 'Software\Python\PythonCore\2.4\InstallPath', '', gPythonInstallPath); end; // Expose gPythonInstallPath to {code:...} clauses. function GetPythonDir(Default: String): String; begin Result := gPythonInstallPath; end; ... procedure SetupDependencies(); var PythonSetupFile: String; PyWin32SetupFile: String; ... begin PythonSetupFile := 'python-2.4.2.msi'; PyWin32SetupFile := 'pywin32-205.win32-py2.4.exe'; ... // Setup python, unless it is already installed. SetPythonInstallPath(); if gPythonInstallPath = '' then begin if not ShellExec('open', ExpandConstant('{tmp}\files\' + PythonSetupFile), '', '', SW_SHOW, ewWaitUntilTerminated, ErrorCode) then FatalError('Unable to install python'); // Try again to find the install path. SetPythonInstallPath(); if gPythonInstallPath = '' then // This shouldn't happen ... but if it does, we dare not leave this // variable empty: the installer blithely goes on to copy files // into the Windows system32 directory if we do. That should never // be allowed. gPythonInstallPath := ExpandConstant('{tmp}\NoPython\'); end; // Setup pywin32 if not Exec(ExpandConstant('{tmp}\files\' + PyWin32SetupFile), '', '', SW_SHOW, ewWaitUntilTerminated, ErrorCode) then FatalError('Unable to install PythonWin32'); ... The key is that the Python installer creates a registry entry, so you can guess whether Python is installed by looking at that. Note that this Inno code doesn't try to do silent installs -- and it always runs the pywin32 installer.
On Fri, Dec 09, 2005 at 10:19:57PM -0500, Tim Peters wrote: | > Supposing there is a existing python installation, how difficult is it | > to get a distutils-based windows installer to be extracted to a random | > directory outside site-packages? | | distutils has no support for that. | | > My guess is that it's basically unzip it. | | What are you trying to accomplish? (I know you're trying to push code | into some directory other than under Lib/site-packages, but I don't | know which code or why.) That would be Zope's code. | > If that's the case, we can simplify the Zope 2 inno installer to: | > | > 1. include a distutils-based windows installer for the Zope 2 source | > 2. include some setup scripts | > | > Then on installation | > | > 1. find or install according python | | Note that Zope also needs pywin32 to be installed. Right. | > 2. unpack the distutils-based windows installer into Program | > Files\Zope | | OK, so you're trying to preserve that ... what? You're neither | sticking Python inside Zope nor Zope inside Python? | | BTW, _how_ do you unpack this at install time? You can't, for | example, assume that a Windows box has any unzip utility (let alone | some specific one). So this part would probably be simpler if you | point Inno at a Zope tree and let _it_ package it and unpack it. | Maybe the way to get such a tree is to build a distutils installer for | Zope and run it on your own box, pointing Inno at the tree it creates, | then throw the distutils installer away <0.3 wink>. Yeah, why not. That would work, I think. | > 3. create a default 'instance home', pointing to the installed python | | An instance home _certainly_ doesn't belong inside the user's Python | -- but maybe I don't know what you mean by these words (I'm probably | misreading "pointing to"). It should be possible to create any number | of distinct instance homes. I mean't 'using the user's installed python'. | > 4. register the services | > | > Steps 2-4 are reasonably simple to me, the tricky one is 1. | | Maybe somone will hit me for this ;-), but we have Inno code for #1 in | one of our other installers. It goes like this: | | [Code] | var | // Path to the user's Python installation, found from the registry. | // Procedure SetPythonInstallPath deduces this. | gPythonInstallPath: String; | | function InitializeSetup(): boolean; | begin | gPythonInstallPath := ''; // don't know yet | Result := True; | end; | | ... | | // Look up Python's install path in the registry. Use HKCU first, because | // a "user-only" instance is supposed to take precedence. If no Python is | // installed, this will leave gPythonInstallPath as an empty string. | procedure SetPythonInstallPath(); | begin | RegQueryStringValue(HKCU, | 'Software\Python\PythonCore\2.4\InstallPath', | '', | gPythonInstallPath); | if gPythonInstallPath = '' then // not in HKCU, so try HKLM | RegQueryStringValue(HKLM, | 'Software\Python\PythonCore\2.4\InstallPath', | '', | gPythonInstallPath); | end; | | // Expose gPythonInstallPath to {code:...} clauses. | function GetPythonDir(Default: String): String; | begin | Result := gPythonInstallPath; | end; | | ... | | procedure SetupDependencies(); | var | PythonSetupFile: String; | PyWin32SetupFile: String; | ... | begin | PythonSetupFile := 'python-2.4.2.msi'; | PyWin32SetupFile := 'pywin32-205.win32-py2.4.exe'; | ... | // Setup python, unless it is already installed. | SetPythonInstallPath(); | if gPythonInstallPath = '' then begin | if not ShellExec('open', ExpandConstant('{tmp}\files\' + | PythonSetupFile), | '', '', SW_SHOW, ewWaitUntilTerminated, ErrorCode) then | FatalError('Unable to install python'); | // Try again to find the install path. | SetPythonInstallPath(); | if gPythonInstallPath = '' then | // This shouldn't happen ... but if it does, we dare not leave this | // variable empty: the installer blithely goes on to copy files | // into the Windows system32 directory if we do. That should never | // be allowed. | gPythonInstallPath := ExpandConstant('{tmp}\NoPython\'); | end; | | // Setup pywin32 | if not Exec(ExpandConstant('{tmp}\files\' + PyWin32SetupFile), '', '', | SW_SHOW, ewWaitUntilTerminated, ErrorCode) then | FatalError('Unable to install PythonWin32'); | | ... | | The key is that the Python installer creates a registry entry, so you | can guess whether Python is installed by looking at that. Note that | this Inno code doesn't try to do silent installs -- and it always runs | the pywin32 installer. Looks great. That will be very useful if I ever get around fixing the Zope 2 installer, which I hope I will. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
participants (2)
-
Sidnei da Silva -
Tim Peters