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

[Christian Vest Hansen]

On Sun, Oct 26, 2008 at 3:26 PM, Niklas Lindström <address@hidden> wrote:
> 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(!).

I _just_ sent out a mail on the `invoke` woes. :)

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

They will find a use if we make the feature available, but we don't
have to do that. However, as per my other mail, evicting `invoke` is
not nearly enough to fix `c31()`, for instance.

> 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.

Do you have other functions in mind appart from `require` and `invoke`?

>
> ----
>
> 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..

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

>
>
> 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
>>
>



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