Fabric maintainer here -- Tav's been quite active on our IRC channel while developing much of this, and it's great to have more people excited about improving the tool!<p>As tswicegood says in another comment, some of these changes (@task, parallelism, etc) aren't unique to Tav's work, so when it comes time to merge we'll draw on the various implementations to see what feels best.<p>The features unique to his fork will be evaluated like any other contribution and merged in if they fit well and are generally useful (which many seem to be).<p>The plan right now is post-1.0 (1.0 is scheduled for Pycon or earlier) to round up a lot of major contributions and get them into core, so people like tswicegood don't have to work off of their own forks quite as much :)
Another cool trick: Integrating Cloudkick tags with Fabric. Using the Cloudkick API - you can express things like "run certain_func on everything tagged 'loadbalancer'".<p><a href="https://support.cloudkick.com/Integrating_Fabric_with_Cloudkick" rel="nofollow">https://support.cloudkick.com/Integrating_Fabric_with_Cloudk...</a><p>We dog food this for all of our production deployments. For example, when we ship a new version of cloudkick.com, we just run "fab ship", which looks for all servers tagged "cloudkick.com" and runs the appropriate deployment script on each of them.<p>Tagging can be done through the CK UI, automatically with the agent, or with things like puppet or chef. This allows you to fully automate deployment and other tasks around groups of servers.
While I like a lot of the stuff you have incorporated into your fabric, it seems to me that you are trying to take credit for things that have existed as branches to the main codebase of fabric for quite a while. Just off the top of my head: task decorators, parallel execution, better host management and command-line task listing all exist in other people's patches. If you have redone the code, good for you, but at least mention that the ideas and prototype implementations aren't yours. (I don't think a claim to ignorance of such is really that valid either, since the Redmine for the project has tickets for most of the things you've done, and has links to the branches containing them).<p>As to getting stuff into fabric: a very valid complaint (and one I have myself, since like a lot of people I run my own hacked version of fabric) is that fabric development moves very very slowly. There are several different feature branches in several people's code-bases that could have been released 6 or more months ago. Perhaps if you start pulling other patches that have a lot of functionality complementary to yours, you could have a product good enough to push development on the mainline too (ala gcc/egcs of old...)
Just a quick note: these features are definitely experimental. The @task decorator has been in stable forks of Fabric for over a year at this point (this is the 3rd, if not 4th independent implementation of it). Likewise, parallel tasks have also been relatively stable for quite a long time.
Did some filter-branching and rebasing to get tav's work on top of current master: <a href="https://github.com/traviscline/fabric/tree/tav" rel="nofollow">https://github.com/traviscline/fabric/tree/tav</a>
This looks nice, but I have to be honest...I'm not going to switch from the version of fabric I use to this. Why? Even though I do have to deploy to more than 30 hosts at once, the thought of the time that would need to be spent verifying that there are no bugs in this would make it impractical to switch. I have to imagine there are others like me who feel the same way. It's a shame that the people this would most benefit are probably the least likely to switch.
I admit to substantial ignorance here, but can anyone who's using fabric, or for whom these patches to fabric are an important improvement, speak to any kind of pro/con comparison they did with func (<a href="https://fedorahosted.org/func/" rel="nofollow">https://fedorahosted.org/func/</a>)?<p>I've been using func for parallel deployment to 15 - 20 servers for about a year now, but I have to admit I didn't really do any research into other options at the time. Its written by the guys who wrote yum and cobbler, which are already core to my setup, so it seemed natural to just stay in their ecosystem. Thing is I never hear about anyone else using it, so I'm curious if anyone did more diligence than I and had specific reasons of choosing one or the other.
The @task decorator is a real good idea. Many good changes in 1.0.<p>The only thing i miss is a virtualenv context manager (with virtualenv(blupp):...).
I've just started playing with Fabric, and I like your take on its functionality better. If they're resistant to merge you, why not fork into something new?<p>You definitely have something very useful there, from a casual read.
Cool ideas. We're just now moving from a 1 machine deployment to a 4 (and probably more) machine deployment at work and I can already see the value in this.
There is definitely some cool stuff in there. I particularly like the @task decorator, the directory support, the context and of course the parallel tasks.<p>Nice work tav.
I cant see how adding such a wast amount of features makes the API cleaner. You made the library more complex than what it already was. Fixing Fabric should in my opinion be done, not in a backwards compatible way, but by forking it and taking away all the crap you don't want, then build a cleaner API. Adding more features to something which already is bad doesn't make it better.
Beautiful work. I've always felt that Fabric strikes a effective balance between simplicity and flexibility and love how you're extending it without breaking its spirit.