[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fab-user] Re: Fabric
From: |
Christian Vest Hansen |
Subject: |
[Fab-user] Re: Fabric |
Date: |
Sun, 22 Jun 2008 23:26:23 +0200 |
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.