Zope 2.7.0b1 was released recently and I'm just now getting my first quick look at it. I'm thinking this will be the most important Zope 2 release since the 2.3.x family. Zope 2.3 brought a lot of usability enhancements - from the ability to use Python Scripts instead of DTML for server-side logic to many API and user interface improvements. It was the first Zope 2 release that I was comfortable using. There have been some nice additions to Zope since then and the 2.6 family has been rather good to us. But Zope has long suffered from another usability standpoint - system administration.
For most of Zope 2's life, you would download Zope, untar it, and run a script called wo_pcgi.py (commonly pronounced as "whoa piggy!"). It would build Zope without PCGI support. Most (but not all) configuration would generally be done in a shell script that set up environment variables and command line switches to get Zope up and running. Few people knew about the environment variables (the ENVIRON.txt documentation file was a fairly recent addition to the tree - and nobody looks at documentation anyways). Nor did they know about some of the flexible Zope options such as the ability to separate the SOFTWARE_HOME (the base Zope software package) and INSTANCE_HOME (an instance with custom configuration and additional components). Separating out the INSTANCE_HOME has the benefits of being able to more cleanly manage a running site separate from the core Zope package - including the ability to easily upgrade to a newer version by changing the software home setting (say from Zope 2.6.1 to 2.6.2) without having to copy and move the site specific settings from one Zope tree to another. Yet to this day, I still see sites running out of directories named Zope-2.6.0-src.
One of the primary goals of Zope 2.7 was to fix this problem. And given my experiences thus far, it seems like the time and effort that has been put into this has been well placed.
The first difference is that Zope can now be put together with the traditional configure; make; make install process. By passing a --prefix setting to configure, one can set up where to install Zope - immediately making the instance home/software home separation easier and more obvious.
At the end of the make install process came the following note, based on my prefix settings:
Zope binaries installed successfully. Now run '/home/example/lib/zope/2.7.0b1/bin/mkzopeinstance.py'Running that script with '--help' presented a list of options to make a new INSTANCE_HOME. Run without options, the script asks questions directly. Basically, all that's needed is where to install the instance home; an initial username/password to access Zope through the web; and ZEO host/port (if running with ZEO). Note that you can still configure and run Zope in-place if desired (instead of running make install, you can run make instance). Prior to this script, making an INSTANCE_HOME required manual work and knowledge of how to set up the Zope start/stop scripts to run in this setting.
As stated earlier, configuring a Zope instance to run required setting environment variables and command line switches in a start script (usually a shell script that wrapped a call to z2.py). Compare this to Apache: I think that a benefit that the Apache web server has had for a long time has been its configuration file. I'm a developer, not a deployer, and rarely ever touch Apache. But I can usually stumble my way through the configuration file, mostly due to the fact that it's fairly well documented in-line, and is filled with meaningful examples. Zope 2.7 finally brings a similar feature to Zope by using ZConfig. ZConfig is a system geared towards writing more expressive configuration files than the simpler .INI files while still having something that's editable by administrators and deployers. When mkzopeinstance or make instance is run, a default zope.conf file is generated. This file is much easier to deal with than environment variables and other configuration options. Most of the documentation that was in ENVIRON.txt is here and commented out, with defaults clearly explained. This is much nicer that what was available in the past because it clues users in to what options they really have in the same place that they're setting them.
Zope 2.7 also comes with a much nicer start/stop system in the form of zopectl. It provides all the basic start/stop functions for controlling the Zope instance, as well as some other helpful commands. I've been using something similar for the past couple of years, and it's nice to see it fully fleshed out and shipping as part of the system.
While the new configuration, installation, and execution capabilities are excellent, it's worth noting a couple of other nice features:
Zope 2.7 has been through some interesting changes in its scope, and has taken its time to show up, but I think the wait will have been worth it. Hopefully the beta cycle will be quick - but solid.