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
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
- 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.