Re: [Fab-user] Does require() still make sense?

[Jeff Forcier]

>> In fact, I it may seldom/never be very useful to invoke commands from
>> within other commands..

<snip>

>> Which brings us back to the question of if
>> people will need "instrumental" functions factored out from big
>> commands. Hitherto I've used "@depends" a lot though, and found it
>> very useful for this -- with the benefit of being able to call
>> "preparing" commands for e.g. setting up dirs or similar. So composing
>> multiple operations with "@depends" is good enough for me currently.

I definitely think being able to call commands within other commands
would be a nice feature, especially in the 'deep' mode where you can
do stuff like "if x: command1() else: command2()". The decorators
can't really help with that sort of thing. In addition, you may want a
block capable of being a standalone command AND being called as a
component of another command.


> That's a good idea. I think @hidden or @private are better names, though.

+1 on @private, or possibly other alternatives like @nocommand or @helper.


>>> It is idiomatic Fabric to use commands for specifying the target
>>> environment of a deployment.

It doesn't obviate the actual point you're making, but, have we ever
considered "baking in" the idea of environments somehow? Especially
given the issues raised about nested use of @hosts (or any situation
where a chain of commands ends up altering the contents of fab_hosts
partway through) we may need to really reconsider how we deal with the
intersection of >1 command and >1 set of hosts. That's for another
thread, though...



With all the edge cases we've been finding lately after merging my
branch and implementing Niklas' changes, I think we may need to
re-examine the overall patterns here and figure out a cleaner way of
doing things, if one exists. We're getting quite complex and
complexity is never good :)

This might involve altering the code between fabfile load and
execution (far less than ideal, of course, but just throwing it out
there), or something else that makes it easier to manage multiple
commands + preconditions + variable passing + calling commands from
other commands + etc.

We might also want to take some cues from e.g. Capistrano; for
example, instead of our current @depends/invoke() setup, they use a
"hooks" system which would look like this in Python syntax:

    def copy_files():
        put(local_file, remote_location)

    def make_dirs():
        run('mkdir /foo/bar/')

    after(make_dirs, copy_files)

When set up that way (though in Ruby it looks more like a DSL of
course), any time you call make_dirs, it will call copy_files
afterwards. I don't know whether the hooks execute _always_, or only
for commands explicitly invoked on the command line, though.


At any rate! I think, before we go a _lot_ further with these kinds of
discussions/changes, we should try to tackle the testing + refactoring
problems. That will make it both easier to hack on, make it harder to
introduce regression bugs, and help us re-examine how we want Fabric
to behave or be used.

-Jeff