Chris McDonough <[EMAIL PROTECTED]> writes: > On Aug 27, 2007, at 10:59 PM, Ross Patterson wrote: > >> We have a Plone 3.0/Zope 2.10 application that we need to develop >> on, maintain and >> deploy to a ZEO server and multiple ZEO clients. Currently we use svn >> bundles of Zope and Plone and our own packages and products in one big >> svn:externals definition. We also use some more recent versions of >> certain products and packages than those included in the upstream >> svn:externals. For example: >> >> Zope svn://svn.zope.org/repos/main/Zope/branches/2.10 >> Zope/lib/python/zope/app/interface svn://svn.zope.org/repos/main/ >> zope.app.interface/trunk/src/zope/app/interface >> >> Though I haven't seen any documentation to this effect, svn seems to >> treat the second svn:externals as a "svn switch" on "svn up". >> >> So one question I have is how would I "override" the versions of some >> package like this using buildout? > > Putting these packages in your Zope instance home's "lib/python" > directory should get them found before the others. For Products, you > can use an additional "products-path" directive in zope.conf and put > files in there. I don't know how to tell buildout to do either, > though.
But wouldn't that cause problems in this case since zope.app.interface is a package in two nested-namespace packages. IOW, wouldn't putting zope/app/interface in $INSTANCE_HOME/lib/python mean that it was the only package in the zope or zope.app namespace packages? >> Another question I have is that there aren't releases for all the >> dependencies our application has. I'm wondering what the best way >> is to >> define a canonical release for deployment to our cluster. Ideally, >> we'd >> have a buildout (or whatever) on a staging server where we're testing >> the candidate for deployment and then when all tests pass that *exact* >> source should be deployed to the cluster. > > I always use a vendor import for this (to a separate CVS server, I > don't use SVN). Yeah, I guess that what we'll end up doing. >> How might one do this without >> upstream releases? Is there a way to get buildout and setuptools to >> play together so that I can build a source distribution from the test >> passing buildout on staging? Is there a way I can have a buildout on >> each cluster node such that a simple ./bin/buildout will get the >> latest >> deployment release for that node? > > Personally I use a script that knows about all of the revisions of all > of the products and packages I want to deploy, and which creates a > "sandbox", downloading and installing all of them (as well as > creating instances, etc). It doesn't work very well for upgrades, > but for starting a sandbox fresh, it's fine. See http:// > agendaless.com/Members/chrism/software/buildit and http:// > www.plope.com/Members/chrism/buildit_example . Thanks, I'll check it out. Ross _______________________________________________ Zope maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
