-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying options (params) for subtasks #321
Conversation
…or the main Task. A step towards pydoit#5 but still misses unit tests and validation of what should actually be done.
…evel (increasing coverage)
I added positive and negative tests. |
This design does not solve the case where argument values are used in the task-creator itself. |
So do you mean what But still I can not determine from the documentation (and I read it quite a number of times now) why the parameters
I'll try to reverse-engineer the code on monday to understand why and if it is a bug or a misunderstanding from my part. |
I mean to be able to use argument value while creating the task dict. Not only on task execution (actions). Something like this
|
yes. this is a limitation: see #283
There is no such a thing of flow of parameters, but...
You can use https://pydoit.org/task_args.html?highlight=get_var#command-line-variables-doit-get-var
This should be achievable after #311 is implemented |
@schettino72 I just read your message again, and it seems that therefore one feature is missing and not already present in the backlog: the capability to expose task parameters to the commandline even when several tasks are run (typically when the default task sequence is run, and the user only calls Even if Shall we open a ticket for this ? I have to admit that you have been closing tickets so fast in the past days that now I hesitate a bit ;) |
@smarie have you read this? https://github.com/pydoit/doit/blob/master/.github/ISSUE_TEMPLATE/feature_request.md If you follow your tickets will have a better chance of not being closed "so fast". |
I have, actually :) and I tried my best to follow it. Apparently that was not enough 😄 |
Very short comment since this is closed... IF @schettino72 thought it was a good idea to have a group-level means to define subtask params THEN I'd suggest moving this from being |
Thanks @rbdixon for this suggestion ! Indeed this is interesting: if there is an existing mechanism to set common It is strange that I did not come across this mechanism in the code where the subtasks are generated... Maybe this is done in a later step. |
A step towards #311 .
I managed to make my propoal work: i.e. a return statement after the generator in a group task will modify the params on the group task AND the ones in the subtasks.
So you can for example write:
Currently it only works if the parameter is passed to a named subtask through the CLI: for example
doit mytask:mysubtask --myparam hello
will give(By the way the title is not updated, this is maybe another issue.)
However the parameter is not correctly propagated if I call the group task instead
doit mytask --myparam hello
yieldsAny idea why ?
I can not figure out from the documentation how to propagate a parameter from the CLI or from the configuration file to a task without naming the task (and in this case the subtask) explicitly. Any help would be appreciated so that I can finalize the proposal.
The PR still misses unit tests and conceptual validation of what is been done: as of now I copy the group task params to all subtasks.
Thanks!