[Zope3-dev] Errors with ZopeX3a2 windows binary

[Tim Peters]

[Jim Fulton]
> Well, we absolutely need a decent windows installer. We definitely plan
> to do that.  I really *want* that installer to be distutils created, as
> I don't really want to be in the business of writing windows installers.

Well, almost no one writes Windows installers -- they write scripts to drive
Windows installer generators.  Windows has elaborate standards for how
installations are "supposed to be" done.  disutils does part of that job,
and does so well, but when scripting against (say) Wise or InstallShield or
InnoSetup instead, you get a veritable mountain of pre-packaged Windows
installation components to build on.  Rewriting all that stuff in disutils
doesn't sound likely to me -- who would do it?  Why would they bother?
Reinventing wheels gets tiresome, and especially when they weigh several
tons each <wink>.

> My hope is that, at least in the long term, we can enhance distutils to do
> what we need.

That needs to be defined for Zope3.  For example, the Zope (2) Windows
installers repackage and install their own Python subset and win32all subset
distributions too.  Is that needed for Zope 3?

> In particular, I think there needs to be a notion of installing
> an application, rather than a library.  An application is like a script
> except that it has it's own home directory, with it's own library,
> scripts, and data files. Zope is not the only application that could
> use this.

That could be done with a plain zip file:  let the user pick a root
directory, and off it goes.

You get another problem then:  how do you get this stuff on sys.path?
distutils wants to install into Python's Lib/site-packages/ on Windows
because that's on Python's path, and that's *why* it's on Python's path (for
the benefit of installed packages).  Zope 2 plays a nasty trick by
installing a site-customize.py on Windows, to get Zope2's non-standard
lib/python into sys.path.  Provided no other installation tries to play the
same trick, it's almost reliable, but not quite (e.g., if the user installs
their own win32all, that both shadows the one Zope2 installs, and has the
surprising side effect of putting the user's Python's Lib/site-packages
before most of the stuff in the version of Python that Zope2 tries to
install).

Those aren't really installer issues, they're trying to tease out that "what
we need" isn't clear, and hasn't been wholly solved for Windows even in Zope
2.