I used to use vellum, and that did what I needed. But fabric being under active development, and getting new features each version it seems is a huge plus. That and it does the network stuff for you, along with the nitty gritty.

Recently I have been giving presentations to the Ohio State University’s Open Source Club about gnu tools, python tools, and soon some cli apps. Fabric really helped make this simple for me to get a whole system down for making and uploading these.

I made all of those presentations in restrctured text, and compiled them into their final formats. All of which was scripted in fabric. I became really attached to ReST after getting introduced to it watching Catherine Devlin give a talk about restructured text at Ohio Linux Fest. I ended up finding a cool rst2s5 command that makes nice presentations and with a little tweaking it now also has syntax highlighted code blocks, and can make nice pdfs.

In starting to use fabric you’ll notice the basic idea is that you’d make a fabfile that works a lot like a Makefile or a SConstruct file would, with make and scons respectively. You’ll make calls with the fab command in the directory the fabfile is located and it will supply the targets.

Below in this example, two targets are made, pack and deploy. The pack target will just makes a tarball, using the local function fabric provides. The deploy target calls pack to make this tarball, then using the put function will place the tarball into the tmp directory, then change into the web dir provided, and extract the archive. It knows automaticly to do this to both hosts I provided, and since I am using an ssh key does all this trickery autonomously.

fabfile.py

Fabric can do a lot more than just this, and its docs have a lot of detail, and explain most everything well.

A last example of some a cool fabric config would be the one I use to publish my presentations to this site.

fabfile.py

This has some more complicated bits, where it uses the role decorator to specify only to use the hosts listed in the production role definitions.

It also takes advantage of an awesome feature I didn’t know fabric had where, one can send arguments to a fabric target. So the project parameter in the targets here can be, and is, supplied via the command line.

For example, I used this to deploy the updates to my most recent presentation:

That’s telling fabric to run the upload target, and send the string “tool_oriented_python” as an argument to the function.

If you forget the targets you have just do:

This then spurred me to take the scripts that were for the most part, copy common-ish bits and then modify to suite, and turn them into a library of sorts. The neat part then arose when I wanted to import a argument parser, as well as pass off to a proc creation component.

In doing this I had in mind that the ‘script’ would need to only define a function to make a list of commands to run on a given server, and a __main__ section that would pass in a list of servers, the function to make a command list and some other info. This way the script itself would only be two definition sections, and only the parts that were going to be unique for the most part.

The problem that came up in doing this is when I wanted the function that makes the command list to have more arguments that normal. How would I pass them in, and how would I define them so that I don’t have to edit my libraries to accommodate this argument passing. It was kwargs that saved me there, that and some optparse tweaking.

Here is a basic example:

script.py

automation.py (library w/ functions)

So this example is a script that defines the function to return a command list, and provides an options var, and list of hosts. The thread hosts then loops over the hosts each time passing the host and the get_commands function to another library function that connects to said host, and loops over the returned command list.

A part that might be confusing is that the parse_args function returns optparse’s options variable but the options.__dict__ representation specifically. This then allows me to be able to update kwargs with any options that I allow to be set at the command line. The example in the script being the key_file variable.

The neat part of all this is being able to take the kwargs for one function and pass it right along to the next. This is key, because it allows for the library function in this case to be able to be entirely decoupled from the script itself.

With this implementation I am able to write a script that defines extra args to use, and only the script need know what they are. In the examples the library will just dumbly pass them along in the kwargs dict, I never have to tell it that I want to pass a user variable to it, and it makes the script a nice self contained unit.