Re: [Fab-user] Exposed tasks via @task

[Jeff Forcier]

Hi Van,

On Mon, Dec 19, 2011 at 1:34 PM, VanL <address@hidden> wrote:

> In this case, frobnosticate.which *is* utils.which. Is it possible to keep
> tasks marked by the @task decorator to the context in which they are
> defined?

Yes and no -- the namespace feature is still pretty new and a little
rough around the edges -- sorry!

"No" in that there's no explicit way to make a task "sticky" to the
context it was defined in. We might try to add this later, though
we're already doing some thorny stuff with how Python imports and
refers to things, so it might not be entirely feasible.

"Yes" in that you can use a couple workarounds to at least partially
manage what shows up as a public task in --list etc:

* Import utils, not utils.which, into frobnosticate.py. In other
words, get the module, not the callable. This prevents 'which' from
showing up 2x in --list output. However, depending on the order things
are imported in, this may have the unfortunate side effect of making
'utils' itself only show up as a child of 'frobnosticate'. So, not
great.

* Use __all__ in frobnosticate.py to limit what it exports to just the
tasks defined within it. This is slightly boilerplate-y, but results
in a cleaner --list output. So if frobnosticate defined tasks foo, bar
and biz, and did "from utils import baz", setting __all__ = ['foo',
'bar', 'biz'] would have the desired effect.

Hope this helps,
Jeff

-- 
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org