3 ms·
Good to hear, hopefully the task decorator will make it in soon because I think it's a much superior API. The little hack on Fabric I use currently takes the o
by jsdalton 16y ago
Good to hear, hopefully the task decorator will make it in soon because I think it's a much superior API.
The little hack on Fabric I use currently takes the opposite approach -- I use an @internal decorator that hides certain functions from the task list but keeps the default Fabric behavior around for anything else. It's just a few lines of codes that mess with a private list Fabric uses to track internal functions:
from fabric.main import _internals
def internal(fn):
_internals.append(fn)
return fn
_internals.append(internal)
- tswicegood 16y agoThat's an interesting idea. I like the idea of turning things off too. In some cases, that's more useful than explicitly defining a @task. Care to open a ticket on code.fabfile.org with it? Maybe we can work that in as an option in 1.1 (when @task is set to hit).
- jsdalton 16y agoSure, I'll try to file one later so it can at least be considered. What I was trying to say in my earlier comment was that I would actually prefer the explicit @task decorator be part of the official Fabric API because it's more clear and, well, explicit. I prefer my @internal decorator as a hack in the meantime because I imagine it's less surprising to someone who might stumble upon my fabfile without any explanation from me.
- bitprophet_ 16y agoYea, definitely add a link to that in http://code.fabfile.org/issues/show/76 http://code.fabfile.org/issues/show/76 please! Might be nice to give people even more control. I think @task is "enough" but if we can have a richer API while not overburdening things, could be a plus.