Dump single config file from your uber buildout

We have the annotate command that buildout provides. It’s great, but what I wish it did was resolve all of the values and give me a usable buildout.cfg that I could potentially reuse, diff, etc. As your buildouts get more modular and flexible, a tool like that becomes more and more important.

Using buildout.extensionscripts, I whipped up a quick proof of concept, that I think might be helpful. I should create a full-blown buildout extension for this someday (prodding is welcome).

The file and an example buildout using it are up on my google code SVN repo.

Here’s how you can try it out (make sure you have the usual pre-requisites for zc.buildout: python, gcc, etc):

$ svn checkout http://lionfacelemonface.googlecode.com/svn/trunk/cfg-dump
$ cd cfg-dump
$ python bootstrap.py
$ bin/buildout -c dump.cfg

Don’t worry, the buildout will exit before anything is actually installed. It will download templer.core, mr.developer, and the one or two recipes that are used in the buildout files. I wanted the dumping process to be as quick and painless as possible, but from what I can tell it’s unavoidable. Buildout will install requisite recies. mr.developer will download templer.core. I wanted to test how my code got along with another buildout extension, and I used mr.developer, and used templer.core since I had it in mind. It seems to play nice but because extensions are evaluated after the config is parsed, but before the installation, I can’t really stop other extensions from doing things if buildout invokes them first.

If you peek into the buildout itself, you’ll notice its kind of contrived and somewhat odd. It’s a mishmash of buildouts I’m currently putting together. It’s not intended to be run directly, but it will probably not fail if you did.

Be careful using the extension on a buildout that you care about; it’s not destructive, but it could use more checks for things like existing dump files and such. It’s also not extensively tested.

Once the buildout is complete (shouldn’t take more than a 20 seconds or so), you will see a file called buildout-dump.cfg. Ta-da!

The formatting of the dumped config leaves a little bit to be desired (buildout section is not at the top, no comments injected or preserved), but it should be runnable. It makes an assumption or two (sections/options prefixed with ‘_’ are skipped, computed values are skipped if they can be detected, etc), so YYMV (please let me know of specific recipes you have trouble with). I consider this a bonus feature at this point, but reliable round-tripping would be pretty cool.

Here are the options available (no configuration is necessary out of the box):

  • dump-skip-empty – boolean. If true, and a value is empty (or false I think, need to verify that – it may not be what we want), omit it from the output instead of outputting param = . Defaults to false.
  • dump-file – the path to a file to put the dump into (the contents will be overwritten!). If this option is set but empty, no file will be written. Defaults to ${buildout:directory}/buildout-dump.cfg
  • dump-eject – boolean, if true, the buildout will terminate after dumping the cfg file. If false, it will proceed to complete the buildout.

The extension also looks at the verbosity level switch (-v). If present, the config file will be dumped to stdout as well as being written.

So please, try it out, let me know how it could be improved (I’ve only scratched the surface of the zc.buildout internals), if you find bugs, etc.

This entry was posted in buildout, plone, python. Bookmark the permalink.

3 Responses to Dump single config file from your uber buildout

  1. Alex Clark says:

    Nice! I would be interested in helping you make this a “real” extension.

    • jjmojojjmojo says:

      Sweet, what shall we call it?

      • Alex Clark says:

        Hmmm, maybe something boring like: buildout.dumpconfig? I picture it can be added via extension e.g. extensions = buildout.dumpconfig, have it dump configs by default every time you run buildout, and allow it to be disabled via: dump-config = false in [buildout] (because you may want to leave it in your base config, but be able to disable it other configs, for example).

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