Get name for context aware task

[darfink]

Is it possible to get the name of the currently running task, if the task is context aware? I can give an example of by describing my current situation.

I want to have one task for each of my application installations, but the logic of these tasks are all identical. That means a lot of boilerplate code.

@task(cask)
def alfred():
  if application_exists('alfred'):
    return
  install('alfred')

@task(cask)
def asepsis():
  if application_exists('asepsis'):
    return
  install('asepsis')

What I would prefer would be to do something like this:

@task(cask)
def install_app(ctx):
  if application_exists(ctx.name):
    return
  install(ctx.name)

ns = Collection()
ns.add_task(install_app, name='alfred')
ns.add_task(install_app, name='asepsis')

Is this possible, or is there any workaround?

[sophacles]

Looking at the code for Task, you should be able to do this, or something similar:

def install_app(name):
  if application_exists(name):
    return
  install(name)

class MyTask(Task):
   def __call__(self, ctx, *args, **kw):
     return self.body(self.name)

ns = Collection()
ns.add_task(MyTask(install_app, name = "alfred"))
ns.add_atask(MyTask(install_app, name="asepsis"))

Although this in my mind brings up a couple thoughts for @bitprophet -

1. Can we get a kwarg to the @task decorators to point at custom subclasses of Task? (this may be done or covered by another ticket already....)
2. Should the Context object point to the specific Task instance being used - so we could do something like ctx.task.name in the above - this gets a bit hairy with all the other stuff being discussed, but it might be useful/needed.

[bitprophet]

Hi!

• I acknowledge that this sort of metadata is useful to be exposed (the lack of a lot of it in fabric 1.x is a big class of complaints/nasty workarounds).
• I too thought there was already a ticket about allowing custom task subclasses in @task but I don't see one, nor is the code currently set up to do it already.
  • Presumably that would be best served by adding a kwarg to @task, which works well for one-offs, and folks wanting to do a more blanket reassignment could reasonably do import task as _task; task = partial(_task, klass=MyTaskClass) or whatnot.
• Having a reference to the task in the context makes some sense re: access to metadata (& given contexts are, at the CLI level, unique per task invocation), but yea it's kinda hairy/gross.
  • The only alternative I see offhand is to copy the interesting bits like name and eg pre/post into the Context. However, this makes sense for other reasons (it jives well with including per-invocation data which wouldn't be present on the Task itself, such as a copy of the CLI arg parse result).

[haydenflinner]

Think you can close this thanks to klass. Very handy feature!