extending a buildout: taking out unwanted parts

I’m working on a suite of buildout configuration files to use for different circumstances. Having a special buildout for development in a zeo cluster, and another for a single monolithic zope instance (plus useful debug tools already installed) was easy to do and is working well.

I then get to the notion of staging vs production. We stage our plone sites on a separate server, often using the staging instance for content development, debugging, etc. The IP addresses everything is listening on, the ports, etc, may need to vary between staging and production, but everything else has to be identical.

The idea of just running bin/buildout -c staging.cfg on the staging server seemed very elegant.

The production buildout.cfg does a lot. I’ve got homemade recipes that set up process control, multiple facets of apache (load balancer, ssl), etc. My first idea was to just duplicate the production buildout.cfg, and then modify it as needed, but I figured that would be hard to maintain. There had to be a better way.

So I read through the zc.buildout docs, and the Adding And Removing Options section caught my eye.

So say my production buildout.cfg file looks like this:

[buildout]
parts = apache
            ssl
            client1
            client2
            zeoserver
... 

[client1]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = me:pass
http-address = 8080

[apache]
recipe = my.apache.recipe
listen = 243.25.21.2:80

[ssl]
recipe = my.ssl.recipe
cert_file = /blah/blah
key = /secure/server.key
httpd_part = apache

... etc, you get the idea

And my staging.cfg file looks like this:

[buildout]
extends = buildout.cfg

[client1]
http-address = 9090

[apache]
listen = 127.0.0.1:5500

So I’m able to selectively override options in arbitrary parts. This is great. I like the idea of making the config that represents reduced functionality subtract functionality out of the other. Worries of having to maintain two files, or worse, have a dissimilar staging environment are mitigated.

But there’s a problem. Let’s say that on staging, I don’t care about SSL. I need to disable this part somehow, and from what I can tell, at least from the docs (code spelunking pending) there’s no way to do this.

I tried using the -= syntax that’s useful for lists of option values:

[buildout]
extends = buildout.cfg
parts -= ssl

[client1]
http-address = 9090

[apache]
listen = 127.0.0.1:5500

If this had worked, it would have been EPIC. But alas, it did not (should it have worked?).

So I poked around some more and checked with some folks on IRC with no luck.

I sort of solved the problem, by just repeating all the parts and then commenting out the ones I didn’t want:

[buildout]
extends = buildout.cfg
parts = apache
#          ssl
            client1
            client2
            zeoserver

[client1]
http-address = 9090

[apache]
listen = 127.0.0.1:5500

This works, but I don’t like it :P

I wonder if this is intentional, a bug, or just an oversight in zc.buildout. I’ll dig further when I’ve got time.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to extending a buildout: taking out unwanted parts

  1. Which version of buildout? There was a bug related to +=/-= recently.

    Try

    [versions]
    zc.buildout = 1.4.1

    and then running bin/buildout -n once.

  2. Just for the records, the += was broken in 1.4.0 and fixed in 1.4.1 but still did not support adding and removing to/from the same key in the same section. This feature was implemented in 1.6.0 and 2.2.0

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s