Re: [Fab-user] spliting fabfile into hosts and functions

[Wes Winham]

Hi Thomas,

I want to echo what Jeff said about Fabric being "just python." As
such, there are a lot of cool ways to set things up, but I'll give the
two different ways I do it (on two different projects):

1. I have a fabfile that just does a bunch of imports like:
> from project_name.deploy.targets import *
> from project_name.deploy.configure import update, copy_data, deploy, new
> from project_name.deploy.aws import ec2_launch

In the deploy package, I have a targets.py that has a bunch of
callable classes that set a whole bunch of different env values. These
are things like what logo to use, what Django settings to override,
what ami to launch with, whether or not I want to configure email
sending, whether or not I should restore from a backup, etc. I use
class inheritance to keep things fairly dry across 20ish deployment
targets, which is much better than the situation I was in when I first
started. targets.py is the file that holds on the configuration stuff,
while all the other files define tasks (with a lot of sub-tasks to
break up the monolithic functions).

2. I started a fresh project after using fabric for project 1, and
decided that reading env values from a config file would be nifty.
I've got a less involved setup, but I have a load_config task that I
pass an argument to on the command line that tells it which section to
use in my config file. ConfigParser makes doing that sort of stuff
pretty easy. It lets me do things like: fab load_config:beta update
deploy

It's really kind of overkill for that particular project, but the
point is that anything you like to do in python, you can do. Pretty
cool.

-wes

> Hello everybody,
>
> what would be the best practice to integrate or include a separate .py
> file that lists my server groups.
>
> (I would like to reuse my functions that are stored in fabfile, but
> also make it consume definitions of groups defining env.hosts that are
> regenerated quite often).
>
> Cheers, Thomas