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

[Niklas Lindström]

Hi,

very good points! I had on my todo to investigate this. :)

So +1 for me.

---

Furthermore, I think the same goes for `invoke`. I just realized it's
even more broken -- if you call it from within another command, it
will actually append another connection, which makes each remote
command repeat(!).

In fact, I it may seldom/never be very useful to invoke commands from
within other commands.. 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.

----

So having both @requires and @depends exlusively used declaratively
both makes it more clean IMHO, and it enables us to even extend the
help system to show this information if we'd like to.

Note that you can also use `requires` to create shared decorators like this:

    _needs_env = requires(
            'host_map', 'dist_dir', 'tomcat',
            provided_by=[staging, production])

    @_needs_env
    def main():
        config.fab_hosts = config.host_map['main']
        config.app_name = 'rinfo-main'

, which I've found useful. It brings is back the "instrumental
callables" thought though.  Perhaps we should be able to "tag" public
callables as non-commands (maybe with an "@instrumental" decorator)?
And make the decorators that @requires return be such per default.
That way I could rename the above to `needs_env` without it showing up
in the list of commands..


Best regards,
Niklas



On Sun, Oct 26, 2008 at 2:30 PM, Christian Vest Hansen
<address@hidden> wrote:
> In light of the new annotations and the changes to how we execute
> commands, let's consider this snip of a fabfile:
>
> def production():
>    "Primes the deployment procedure to execute against production."
>    config.fab_hosts = ['localhost']
>
> def staging():
>    "Primes the deployment procedure to execute against staging."
>    config.fab_hosts = ['127.0.0.1']
>
> It is idiomatic Fabric to use commands for specifying the target
> environment of a deployment.
>
> But with the changes to how we execute commands, we are now much more
> eager to connect and the check for the existance of a `fab_hosts` (and
> a need for one) is now done earlier than it used to (in
> fabric.py:1300-13002).
>
> So much that this breaks:
>
> def deploy():
>    require('fab_hosts', provided_by=[production, staging])
>    sudo("whoami")
>
> However, we've also grown an alternative method of providing the same
> functionality that works:
>
> @requires('fab_hosts', provided_by=[production, staging])
> def deploy():
>    sudo("whoami") # the final deployment step.
>
> So that got me thinking; why do we still have `require()`? With the
> decorator, we now have two ways to do one thing, except one of these
> ways is broken. I suggest that we remove `require()` let the decorator
> be the only way to do this.
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>