#227: Add buildout to the Plone Installer for Windows

Contents

1. Definitions
2. Motivation
3. Assumptions
4. Proposal
5. Implementation
6. Deliverables
7. Risks
8. Progress log
9. Participants

Proposed by

Sidnei da Silva

Proposal type

Architecture

State

being-discussed

Definitions

Motivation

Since Plone has started heavily using buildout, lots of documentation has been created on maintaining, deploying and developing Plone sites using the buildout-based approach.

The PLIP #209 describes the approach taken for buildout-enabling the Unified Installer. However, not everything that was done for the Unified Installer applies to a Plone Installer for Windows.

This proposal aims to spark a discussion on what are the best approaches for a buildout-based Plone Installer for Windows.

Assumptions

Proposal

Creating a buildout-based Plone Installer for Windows has it's share of challenges. While things are different in that platform, they are not necessarily worse. To the contrary, the situation might actually be slightly better for the person using this installer, because more things will be pre-built.

Differently than on *nix platforms, Python extension modules on Windows tend to be statically linked, instead of dynamically linked. That means there's no reason at all for building those extension modules on the target system. Instead, a buildout-based Plone Installer for Windows can (and should!)  ship with pre-compiled binary modules as much as possible.

New recipes might need to be created to handle this appropriately. Or existing recipes could be changed to accomodate for it.

Beyond that, this installer could (should?) also ship with a working, open-source compiler. Tarek has created a zip file with pre-configured Python and MingW which can be used as the basis for this. This compiler would be setup in such a way that simple extension modules that require no external libs to link against could be easily compiled by buildout.

Similar to the Unified Installer, the Installer for Windows should ship with a .buildout cache of the necessary packages.

Implementation

Building the buildout-based Plone Installer for Windows should be handled itself by a buildout. There should be a recipe which generates an Inno Setup (or some other installer) configuration and runs Inno to generate an installer. This buildout should compile (or extract from a binary installer) Python, PyWin32 and Zope at least. Those compiled packages end up in the buildout cache and something similar to plone.recipe.zope2instance would be able to consume it.

The installer should definitely ship with ZopeSkel and Paste, so that you can create alternative buildout configurations.

Deliverables

1. A recipe for building an Inno Setup installer.
2. A recipe that generates something similar to Tarek's pre-prepared environment, or that consumes Tarke's zip file into a buildout.
   
3. A new recipe, or modifications to existing recipes to consume a binary Zope and Python installers instead of building them from scratch.
   

Risks

Should the Installer for Windows be able to be uninstalled? That is when it is installed, should it create an entry in 'Add/Remove Programs' on Windows?

My suggestion is that it should not, for two reasons: 1. That could cause confusion with multiple installs. 2. When uninstalling, lots of cruft could be left behind.

Should the Installer for Windows ship with a working buildout.cfg and override existing ones?

My suggestion is that it should not. Otherwise we risk overwriting a customized buildout.cfg. Alternatively, we could ship with ZopeSkel pre-installed and have scripts for generating a buildout.cfg.

Should the .buildout cache be shared between different installs?

My suggestion is that it should. Otherwise if you run the installer multiple times (see first entry) you would end up with multiple copies of the .buildout cache, using a lot of space.

Progress log

Participants