|
Project Information
Featured
|
What is zappy?zappy is a tool for managing remote deployments using standard Python syntax. Using zappy, you can administer many machines simultaneously from one script, with a mixture of Python and shell commands. To use zappy, simply define zapfile.py in your deployment directory: import pytoss
@pytoss.task
def hello_world():
'''prints a hello world message to the screen'''
print "hello world, we just executed a task"
@pytoss.task
def goodbye_earth():
'''prints a goodbye message to the screen'''
print "goodbye earth!"
Then, type zap on the commandline to see these summarized: $: zap zap hello_world # prints a hello world message to the screen zap goodbye_earth # prints a goodbye message to the screen You can then execute either of these tasks easily: $: zap hello_world hello world, we just executed a task success! And thats all there is to it. Installing zappyFor the current release: $: sudo easy_install zappy If you want to live on the bleeding edge: $: svn export http://zappy.googlecode.com/svn/trunk/ zappy $: cd zappy && sudo python setup.py install Tell me morezappy is most similar in purpose to Capistrano, a deployment DSL written in Ruby. However, zappy intends to remain simple at the core. The core features will not be intertwined with each other, nor with extra "recipes" for special-case deployments. Alternatives
FAQWhy not Capistrano? Ruby is great for writing simple DSLs. However, since most deployments are simply tasks that consist of a series of shell commands, a DSL is not necessarily required. It is often difficult to debug Capistrano issues due to the heavy use of closures and context. Things like setting global variables requires an odd "set" syntax. Many of Capistrano's best features are locked up in recipes that make a lot of assumptions. Overall, Capistrano is just not simple enough. Finally, many people in the Python community have asked for a Python equivalent, and it seems appropriate to provide one given Capistrano's weak points. Why not Fabric? After trying Fabric, it just felt too much like Capistrano. For example, Fabric uses a set() method to declare project globals, rather than actual global variables. Also, every method in a Fabfile is assumed to be a task - you cannot specify which methods are tasks using a decorator. Fabric's syntax does not have the concept of separate roles - you must specify a set of servers to run all of the commands on. This is inflexible for remote deployments that have multiple machines with different roles (application vs. database) that must be administered simultaneously. There is no built-in support for interactive Expect-like input, which is helpful for many deployments, and necessary for anything that requires "su". Even simple things - namespacing, detailed execution logging - are not present yet in Fabric. Although Fabric could be improved in some of these areas, the core Capistrano-like "magic" syntax didn't quite feel Pythonic. Without overhauling Fabric itself, it seemed more appropriate to create a separate project. |