[Zope-dev] Zope tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Dec 8 12:01:02 2005 UTC to Fri Dec 9 12:01:02 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:19:42 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003746.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:21:12 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003747.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:22:42 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003748.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:24:12 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003749.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:25:42 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003750.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:27:12 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003751.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:28:43 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003752.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 8 23:30:13 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003753.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Windows Installer for Zope 2.9+
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: Locale-specific Text Collation
When presenting users with ordered text (e.g. sorted lists of options), simply sorting Unicode strings doesn't provide an ordering that users in a given locale will find useful. Various languages have text sorting conventions that don't agree with the ordering of Unicode code points. (This is even true for English. Generally, users prefer to see text sorted without regard to case.) A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] RFC: Locale-specific Text Collation
On Friday 09 December 2005 08:58, Jim Fulton wrote: A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1 as said on IRC. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] RFC: Locale-specific Text Collation
Stephan Richter schrieb: On Friday 09 December 2005 08:58, Jim Fulton wrote: A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1 as said on IRC. AOL! err. I mean: +1 Tino. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: Locale-specific Text Collation
Jim Fulton wrote: When presenting users with ordered text (e.g. sorted lists of options), simply sorting Unicode strings doesn't provide an ordering that users in a given locale will find useful. Various languages have text sorting conventions that don't agree with the ordering of Unicode code points. (This is even true for English. Generally, users prefer to see text sorted without regard to case.) A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1, no comment :) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR So here's what I'll do: 1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO. 2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3. 3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log. So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. Florent Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFV: Unicode in Zope 2
A few weeks ago, I mentioned 3 big things I'd like to see for merging Zope 2 and Zope 3: - Common Publisher - Common Security frameworks - Common ZPT implementations I forgot a very important need: - Common approach to Unicode In particular, In Zope 3, all text is stored and managed as Unicode. The publisher decodes request data and encodes response data. The vast majority of application and library code can ignore encoding issues. (The exceptions are applications and frameworks that need to exhange text with non-Unicode-aware external systems.) This has provided great simplifications and allowed us to avoid common pitfals from mixing Unicode and encoded text. We need to migrate Zope 2 to use a similar strategy. We need volunteers to brainstorm how this can be done and make one or more proposals. This is likely a prerequisite for finishing the publisher and ZPT work. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Checkins] SVN: Zope/branches/ajung-zpt-integration/lib/python/Products/ZPT/ZPT.py eeek...Zope 3 ZPTs now work in Zope 2 :-)
On Fri, Dec 09, 2005 at 09:25:51AM -0500, Andreas Jung wrote: | +try: | +from webdav.Lockable import ResourceLockedError | +from webdav.WriteLockInterface import WriteLockInterface | +SUPPORTS_WEBDAV_LOCKS = 1 | +except ImportError: | +SUPPORTS_WEBDAV_LOCKS = 0 Never understood this. The interface has been there since when? Zope 2.6? Why is it in a try: except in new code? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Please vote about conflict errors logging
On Fri, Dec 09, 2005 at 03:45:18PM +0100, Florent Guillaume wrote: So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. +100 -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Please vote about conflict errors logging
On 9 Dec 2005, at 14:45, Florent Guillaume wrote: So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. +1 jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Please vote about conflict errors logging
On Fri, 2005-12-09 at 15:45 +0100, Florent Guillaume wrote: So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. Florent +1 A ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Please vote about conflict errors logging
Florent Guillaume wrote at 2005-12-9 15:45 +0100: ... So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. +1 -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR So here's what I'll do: 1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO. OK, I can live with that. I was going to suggest a config option, but defaulted the other way. 2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3. 3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log. So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. +1 to that (as long as we leave Unauthorized, NotFound, and Redirect excluded by default). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmfRJ+gerLs4ltQ4RAnRoAKCiWk45LPc55C71Uuji6qGHgfEnfgCfbHvr fpKYRC+teAopydRnW6esJmA= =IR1c -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Windows Installer for Zope 2.9+
...
[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.
Re: [Zope-dev] Windows Installer for Zope 2.9+
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
