[Chicago] Capistrano alternatives

[Jason Huggins]

On Fri, Jan 2, 2009 at 1:08 PM, Kumar McMillan <kumar.mcmillan at gmail.com> wrote:
> On Fri, Jan 2, 2009 at 11:25 AM, Garrett Smith <g at rrett.us.com> wrote:
>> I'm noticing that Capistrano is showing up in projects that need to deploy
>> and configure software across multiple servers. That's cool.
>
> Even though Jason makes an excellent point about POP, it is sort of
> annoying to roll your own execute-on-remote-server thing.  Python's
> answer to this is paramiko and the Python+paramiko answer to
> deployment tasks à la Capistrano is Fabric http://www.nongnu.org/fab/

Agreed re:paramiko. The one super-annoying thing about using os.system
for calling ssh or scp commands is not being able to see the live
standard output of the remote shell immediately as it runs. With
Paramiko, you can pull/poll the remote stdout and stderr as often as
you want and display it to your local console (or do whatever you want
with it) whenever you want.

Side note: I was going to rant about why I'm spooked by Fabric's use
of the GPL. (Rake and Cap use an MIT-license, which I'm much more a
fan of.) My fear/rant was that Fabric-based build scripts would also
need to be GPL'd since they depend on Fabric. However, after reading a
section of the Free Software Foundation's GPL FAQ [1], I feel slightly
more safe in thinking that Fabric-based build scripts are considered
"data" to the Fabric program in this scenario. Therefore, Fabric-based
build scripts are *not* bound by the GPL. Do others agree? (I hope
so!)

Side-side note: Although, I am generally a fan of POP for my own
builds, it would be nice to see some tool "win" in Python-land as a
rake/cap equivalent. Since Fabric files are "just python", it mostly
matches my POP+libraries ideal. Perhaps with Fabric (as long as I
don't have any GPL issues using it) I can have my cake and build it,
too.

cheers,
  hugs

[1]: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL