We were lucky enough to get together at the New Orleans Plone Symposium several people who care about and work on the installers. Ian Anderson, Joel Burton, Alexander Limi, Sidnei da Silva and I spent a few hours brainstorming concrete improvements that could be made in a short time. Several of these are now available in experimental versions of the Windows, OS X and Unified (Linux, BSD, OS X, Solaris ...) installers for Plone 3.1.4.

All are available at http://plone.org/products/plone/releases/3.1.4 . Look for “Experimental.”

Please try them out and file bug reports and improvement suggestions to http://dev.plone.org/plone -- under the appropriate “Installers” category.
Highlights of what’s available and what’s coming:

Buildout

Sidnei’s put together a buildout-based version of the Windows installer, and I’ve gotten one going for OS X, which means that all the major platforms now have a buildout capable installer.

OS X

The new version of the OS X binary installer (only available at the moment for Intel and Leopard) now has installation options including cluster or standalone and admin or user installs; it also allows you to set the Zope admin password on installation. And, it has some pretty, new Plone icons.

Unified Installer and OS X Binary

Some of the new features that are (more or less) implemented in the new “ex” OS X and Unified installers:

• A new “bin/plonectl” shell script will start and stop all Zope components
• The installed buildout.cfg files start with commented-out example add-ons for popular and development products. (The framework team will make the final choices.)
• Also in the installed buildout.cfg:
• A commented-out "unpinned" Plone definition
• buildout.cfg should have more comments and better order
• The default install will filter deprecation warnings by default. Developers may turn them back on.
• paster and ZopeSkel are managed by buildout, so that they may be updated easily.
• The default install path for the Unified Installer is now /usr/local/Plone; the OS X installer /Applications/Plone. We’ve removed the version suffix because the in-place update capabilities of buildout make it less meaningful.
• The old default page at the root of the ZODB is replaced with one that mentions Plone. (This will be refined before the 3.2 release.)

I recently wrote a buildout recipe that some Plone folks might find useful.  One of my current OpenPlans-related tasks is improving our caching and load-balancing setup.  After a bit of research I decided to start serious testing with Varnish for caching and nginx for load-balancing.  Since both of these have decent buildout recipes from which to start, buildout was a natural choice for a build and deployment management tool.

One of buildout's strengths is that, ultimately, all you need is a single buildout.cfg file to define your entire deployment.  You can then check this file into a VCS repo somewhere, and you (or anyone else) can replicate the entire software stack with one checkout from the repository and one command.

When using buildout, however, I frequently found myself checking out the same buildout.cfg file and then tweaking it slightly, to change such values as port numbers, host names, and passwords, from deployment to deployment.  This was annoying to do, and left me with uncommitted local changes that I had to take care not to commit back.  Neither was I excited about the prospect of managing the versioning for each of these buildout.cfg files separately, when the only thing that varied between them was minutiae.

topp.recipes.cfgtemplate eases this process by allowing you to specify variable substitutions in your buildout.cfg file.  Here's how the plone.recipe.plone recipe (echo?) config file might look:

[buildout]
parts = cfgtemplate plone zope2 instance
eggs =
develop =

[cfgtemplate]
recipe = topp.recipes.cfgtemplate

[plone]
recipe = plone.recipe.plone

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = {{admin-userid}}:{{admin-password}}
http-port = {{http-port}}
debug-mode = {{debug-mode}}
verbose-security = {{verbose-security}}
eggs =
    ${buildout:eggs}
    ${plone:eggs}
zcml =

products =
    ${plone:products}
    ${buildout:directory}/product

Note the use of {{double curly-braces}} around variable names in the [instance] section.  When the user runs buildout against this file for the first time, she will be interactively prompted to enter the values for these variables, which will then be stored in a cfgsubs.cfg file for use during subsequent builds.  The settings persist, but the buildout.cfg file itself is not changed.

The recipe sort of abuses buildout at the moment by claiming to have installed a file even though it didn't, so that buildout will re-install the part (i.e. perform the value substitutions from cfgsubs.cfg) every time.  There's probably a better way to do that.  It's proven immediately useful, however; here's the buildout.cfg for our nascent Varnish and nginx build setup.