Hi Van, On Mon, Dec 19, 2011 at 1:34 PM, VanL <[email protected]> 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 _______________________________________________ Fab-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/fab-user
