Ticket #9568 (closed PLIP: fixed)
Add buildout to the Plone Installer for Windows
Reported by: | dukebody | Owned by: | smcmahon |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Installers | Version: | |
Keywords: | Cc: |
Description
http://plone.org/products/plone/roadmap/227
This proposal aims to change the Plone Installer for Windows similarly to PLIP #209, such that the Plone experience is consistent across all platforms
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
- A recipe for building an Inno Setup installer.
- A recipe that generates something similar to Tarek's pre-prepared environment, or that consumes Tarke's zip file into a buildout.
- 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
Completed with 3.2