[Fab-user] Re: Fabric

[Christian Vest Hansen]

On 6/22/08, Jeff Forcier <address@hidden> wrote:
> On Sun, Jun 22, 2008 at 8:27 AM, Christian Vest Hansen
>  <address@hidden> wrote:
>
>  <big snip here -- thanks for the reply!>
>
>
>  > I currently have two git repositories; one on nongnu.org and the other
>  > on github, and I'm manually keeping the two in sync. Even though the
>  > nongnu repo is declared the "main" one, I think it is easier to do
>  > collaborative development on github.
>
>
> Agreed. I'm pretty sure Git lets you define a post-update hook which
>  could be used to remove the need for manually pushing from nongnu ->
>  github -- I just spent a few minutes Googling and didn't find anything
>  simple-n-easy, however. Let me know if there's anything I can do to
>  make collaboration easier, in terms of branching/commit
>  granularity/etc.
>
>
>  > This is a troublesome subject. For instance, get this: with "rolling"
>  > fab_mode, commands run in parallel, while operations run serially.
>
> > [...] It would be possible to add a third mode that runs the
>
> > commands in serial, but doing so would require a refactor of how this
>  > mode system is put together - which isn't an intirely bad idea, but it
>  > will probably take a little while to get right.
>
>
> Interesting -- I haven't read all of fabric.py yet, which is why I
>  jumped to conclusions upon seeing the word "rolling" :) Good to know
>  the current state of things.
>
>  It sounds like you understand the intent of the functionality I'm
>  looking for, so let me ask you -- am I crazy? On occasion I'll find
>  myself wanting to do X, where all existing implementations of a given
>  program seem to only offer Y, and much of the time I find that it's
>  because X isn't really the right way to approach the problem after
>  all.

I don't know if it's crazy or not, but in this particular instance it
is easier to do Y than X. Also, when it comes to deploying web
applications, you usually don't need complex decision logic. So, in
other words, the bang/buck ratiois low. That, I think, would be why
such functionality is not part of tools like Fabric and Capistrano.

>
>  However, being able to execute non-simple logic on remote systems
>  sounds, to me, like a natural evolution of what Fabric and Capistrano
>  currently offer -- i.e. going from a simple series of imperative
>  commands to a setup involving logic. I recognize that such an
>  evolution is nontrivial from the perspective of the underlying code,
>  but I don't see any obvious failings in the desired functionality
>  itself...?

It might be the next step, but as you say, the code is non-trivial.
Still, all it takes is a guy or gal with an itch plus the time and
skill to do something about it.


>
>
>  At any rate, I'll continue reading over your source so I know how it
>  all works, and possibly tweaking things here and there as I go. I am
>  also thinking of writing some simple API-like documentation that goes
>  beyond your tutorial, just to help myself get a handle on what
>  commands Fabric currently offers to end users.
>
>  I tried running epydoc, but Fabric-the-module has a number of public
>  functions that seem effectively hidden to users of Fabric-the-program
>  (and thus the resulting "API" had a lot of stuff end users would not
>  care about), so I think a manual document is best for now.

Yeah, it's only meant to be used as a module by a bootstrap script.
And I haven't been using these api-doc tools myself, so nothing about
Fabric as been built with them in mind.
What might be useful is a "how to hack Fabric" document. I don't think
that people who just use Fabric normally have any particular interest
in api-docs.

>
>  Regards,
>
> Jeff
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.