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.
Zope3-users mailing list