Ian Bicking: the old part of his blog

Zope software and instance home?

So what you're saying is that Zope is on to something with its software home and instance home? For those uninitiated, a Zope instance is what you would start and can respond to requests. A single piece of installed Zope software can be used to create multiple instances. Packages can either be placed in a particular instance (instance home), in which case they're instance specific, or in the software home, in which case they are available to all instances of that version of Zope. Rarely packages are placed in site-packages.

New versions of Zope installed result in their own software homes, and can have their own instances.

So what we could do is formalize some of these concepts and create a more generic way to do all this going beyond Zope. Zope can then fit into that pattern.

Comment on site-packages Considered Harmful
by Martijn Faassen


Yes, very much like the instance home. Jim was just asking about how that and setuptools would interact recently as well, and Phillip was talking about local plugin directories, and I realized site-packages was just becoming a global plugin directory, and that this global plugin directory cause me nothing but pain. So figuring out how to use setuptools with Zope instance homes, and then how this interacts with plugins and development and other use cases, could lead to a much more pleasant experience for everyone.

One of the issues with the Zope instance home is that Zope "owns" the home, more or less. It specifically is not part of the home. But every other piece of software is part of it. But there are many situations where no one piece owns the working set of packages, it is something more abstract. But if you install a command-line tool, I would expect it to be contained by the home similarly to how anything else might be contained. But if you are installing a web application that uses Paste, I would expect PasteScript (and the paster command) to be part of that same home, and not have a home of its own.

So I think these instance homes -- or "working sets" -- need to be more abstract than belonging to any one product. For some packages -- Zope being notably large (nay, absolutely huge) -- you also don't literally want a complete copy of the package in each instance home. So we have to consider how these can be centrally managed in some fashion. I think setuptools .egg-link provides the tool for saving disk space. The reporting tools to manage all the links and instance homes are still a big deal, and don't exist yet.

# Ian Bicking

+1 on the idea of INSTANCE_HOME. However, I think you do want a globally-installed executable that "owns" the instance. Think of the instance as a word processing document, and the executable as your word processor. Files and applications, man. The zen is in defining a generic-yet-coherent problem domain for the application: word processing, spreadsheets, presentations.


httpy hits the generic-yet-coherent sweet spot for the "website" problem domain. The httpy executable "owns" an instance. Instances can contain multiple sub-apps, each with their own libraries located in situ. So, for example, a single site could integrate a CMS written with Zope 3, a Roundup issue tracker, and a custom contact form, let's say. You also get sitewide in- and outbound hooks for centralized security, templating, etc.

Full docs at http://www.zetadev.com/software/httpy/.


"[Y]ou also don't literally want a complete copy of the package in each instance home."

Why not? Disk space is definitely not the limiting reagent.

# Chad Whitacre