[Zope-dev] Re: [Zope3-dev] December release post-mortem

[Tim Peters]

We should distinguish between authoring the Windows
build-the-installer code, and running that code.  "Making a Zope 2
Windows release" consists of _running_ the build-the-installer code,
and is easy.  It's actually easier than building a Zope 3 Windows
release:  once the Python tarball, Zope 2 tarball, and pywin32
installer are downloaded, building a Zope 2 release consists of typing
one command in a Cygwin shell:

    WinBuilders/buildout zope

That's it.

_Authoring_ the Zope 2 build-the-installer code has been a royal PITA,
but work is needed there only when packaging gimmicks change.  Like
moving to zpkgtools, or moving away from them again, or moving to a
different packaging system for one of the components (like Python
moving from a Wise installer to an MSI installer for 2.4, or pywin32
earlier moving from a Wise installer to a distutils installer). 
Across the long life of Zope 2.7, those things changed very little,
and as a result very little needed to change in the
build-the-installer code across 2.7's life.  2.7 Windows releases
remained easy to build across that time (granting that Mark Hammond
did the work to adjust to pywin32's packaging changes).

2.8 Windows releases were/are similarly easy to build.

A lot of new work was needed for 2.9, due to Python and zpkgtools
changes.  I also took the opportunity to "upgrade" from InnoSetup 4 to
version 5, which introduced a much easier scheme for managing the
custom dialog screens in the Zope installer.

All of that ended up making the build-the-installer code substantially
simpler, to the point where it now seems kinda goofy to use makefiles
at all in the process.  Makefile mazes are inscrutable, and are
particularly ill-suited to the true nature of this task:  "unpack
various tarballs, and rearrange them like so".

Finishing a Windows release of Zope 2 or Zope 3 takes much longer than
just minutes, unless you skip testing.  If you do skip testing, then
it's minutes for both.  Testing Zope as a Windows service is harder
for Zope 3, because the Zope 3 installer doesn't (but the Zope 2
installer does) install or start the service, or auto-stop and remove
the service when Zope is uninstalled.  BTW, Zope3 _could_ do that too
with a suitable post-install/pre-uninstall script, which is something
InnoSetup automates for Zope2.

It can take a Windows expert some days to author Zope2
build-the-installer changes when packaging fashions change (whether
Zope's or the repackaged components').  InnoSetup is the least of the
problems there, and while MSI is the coming fashion, slinging MSI code
appears to require much more knowledge than slinging InnoSetup
declarations.

The idea that it takes "Windows expertise" to write an InnoSetup
declaration is wrong:  such lines merely say "take the files you find
_here_ now, and put them _there_ when the installer runs".  For
example, this is the entire Inno code needed to install Zope 2's lib/
directory:

Source:"lib\*.*"; DestDir: "{app}\lib"; Flags: ignoreversion recursesubdirs

That kind of stuff is truly trivial.  It does take Inno expertise to
create and manage the installer's dialog screens ("manage" == e.g., if
the user chooses not to have the installer create an instance home,
then the dialog asking for the instance home's directory shouldn't be
shown), but those typically don't change across releases.