On Jan 23, 2008, at 1:19 AM, Jeff Shell wrote:

When developing and/or deploying using Buildout, how do you deal with
the Data.fs? I'm particularly concerned with running on different
environments (desktop development, server development, staging,
deployment) as I don't want the Data.fs to be under source control nor
inside the application package at all, really. In some of my playing
around, I've often blown away the local Data.fs, either by doing a
'git clean' or just by tinkering with my buildout.cfg.

We use buildout-local ZEO servers in development.

In production, ZEO servers are deployed separately.

In staging, we deploy specialized ZEO servers that wrap demo storages around read-only file storages opened against production databases. (I'm finishing 2 projects, zc.demostorage2 and zc.beforestorage that will make this much easier, more efficient, and more flexible.)

I know that buildout supports extending other buildout.cfg files. Is
the best option to have a different buildout.cfg for every

That's what we do. We have a buildout config that we use for development, once that we use in conjuction with zc.sourcerelease to create RPMs for deploying production software. We also have production buildouts that configure instances and associated run-time scripts, configurations, and support files, Stage is not really different from production in this regard. The same software RPMs are used for both. They differ only in the instance configurations.

As a side question then, is buildout:directory relative to a config
file, or relative to where buildout is being run? I'd like to have a
base buildout.cfg in the base, but put the others in a sub-dir.

By default, it is relative to the config file. You can override it to be whatever you want.


Jim Fulton
Zope Corporation

Zope3-users mailing list

Reply via email to