command line arguments for task creators

doit already support Task parameters, but they are not convenient to be used with task-groups.

Example of proposed feature:

from doit import task_param

@task_param({'name':'param1', 'short':'p', 'default':'default value'})
def task_py_params(param1):
    for name in ['foo', 'bar']:
        yield {
            'name': name,
            'actions':['echo {}'.format(param1)],
        }

doit would be responsible for injecting parameter values when executing task-creator functions.

[rbdixon]

Well, strictly, none of them… though they are all interesting (and valid) usage considerations. My only intent was to provide a way for a task creating function to access command line arguments. In my own doit-based automations I’ve done weird things to compensate for not having this particular behavior. Other examples where people have gotten stumped without this feature:

• https://stackoverflow.com/questions/57045829/dynamic-target-names-in-python-doit
• https://groups.google.com/forum/#!topic/python-doit/Xkw7SaAnkdg

I used a decorator because a) that’s what @schettino72 proposed, and b) it makes sense because if one wishes to preserve the doit-style of using a normal Python function arguments to deliver command line arguments to the task generator the definition for those command line arguments must be available before the task generating function has executed. Something other than a decorator could be used, of course, but a decorator at least puts the definition right next to the the function that will benefit from it. There could be other ways, though!

What you implemented in PR #321, IMHO, could be useful. I’ll leave a comment on that PR.

[smarie]

There seem to be several features behind this ticket:

• first, the fact that a “group task” exists as a task in doit, even if the user is not aware of it today. We could offer the user with the capability to edit that group task. This is the direction proposed by PR #321, and it could go much further (adding actions executed at the end of the group for example).

• second, the fact that subtasks in a group do not today have the possibility to inherit from common group behaviour, in particular parameter definition. This is also the direction proposed by PR #321: when the user defines a parameter on the group task, it is copied on all subtasks.

• finally, the fact that parameters could be defined in a more intuitive way using a decorator. I insist that this does not seem specific to subtasks at all, except if I misunderstood something (@schettino72 can you confirm ?). If we go down that road of providing decorators, users will of course ask for more and ask that every aspect of tasks could be determined with decorators… Just like in letsdoit. That is why at first I was not fond of using a decorator here: just for API consistency reason. Since current API heavily relies on generator api, it was more consistent to continue to use it.

@rbdixon which part of the above topics does your PR tackle ?