On Tue, Feb 15, 2011 at 6:47 AM, Michael Gliwinski
<address@hidden> wrote:
> There are two use cases. The one you mentioned (fab production.deploy, fab
> staging.deploy). I use that quite a bit.
>
> The other case that I'm hoping this encourages is shared stuff. For
> example fab apache.restart, fab django.init, and so on. This would make
> it possible for people to package common tasks and distribute them that
> way. I know of several developers (myself included) who started down this
> path only to discover we had to use PEAR-style prefixing for everything.
Wouldn't shared functionality rather be something that you use in tasks in
your fabfile rather than exposing it as tasks on command line? I mean, yeah
there are few small and simple bits like <some_service>.restart or shell or
even wrappers for some remote commands you may run interactively like grep,
etc. but most of shared stuff I have is utilities/objects I only use in
actual fabfile tasks.
... snip ...
Do you have lot of shared functionality which is exposed directly?
It's mixed. I have a lot of tasks that are completely useful on their own or composed as part of a larger package. For example, my rabbitmq tasks[1] are normally combined into a rabbitmq_init task that sets it up the way I expect, but it's also nice to be able to interact directly with rabbitmq as needed.
Look at it this way: modules/packages with shared functionality have to be
installed globally (specifically somewhere on Python's path so it's accessible
from different fabfiles), now for example you have a module 'apache' which
provides ways to start, stop, configure, check status of the server, etc.; now
you have a fabfile which is meant to be used by support group for diagnostics
of various systems including an apache server; if you import that shared
apache module to get the status command all of a sudden you also get one to
reconfigure the server.
You could always import simply the status function from the apache module. All this code does is scan the fabfile looking for potential modules. If you don't have an `apache` variable, it's not going to know there's anything there to scan.
All that said, what you're describing here is a selective import of tasks that retain their module relationship. I love that idea, but I think it's a next version of this. The first version should be dead simple (either a variable signifying task modules or some Fabric API for signifying task modules) and we can start doing things like filtering as a second version.
-T