-
Notifications
You must be signed in to change notification settings - Fork 59
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
Issue with composing tasks with output_file_template in a workflow #641
Comments
The issue is here. Looking at the following code extraction: def template_update_single(...):
...
if spec_type == "input":
if field.type not in [str, ty.Union[str, bool]]:
raise Exception(
"fields with output_file_template"
"has to be a string or Union[str, bool]"
)
inp_val_set = inputs_dict_st[field.name]
if inp_val_set is not attr.NOTHING and not isinstance(inp_val_set, (str, bool)):
raise Exception(
f"{field.name} has to be str or bool, but {inp_val_set} set"
)
if isinstance(inp_val_set, bool) and field.type is str:
raise Exception(
f"type of {field.name} is str, consider using Union[str, bool]"
) Since |
One possible solution would be for But I believe it would fail further down at the formatting stage where the actual value needs to be accessed. It looks like Unless I missed something? |
Fixed by #662 |
I am attempting to build workflows which compose shell command tasks together, some of which providing default output names via
output_file_template
. However, these trigger an exception at runtime if they are not explicitly set when running the workflow, which defeats their purpose in my opinion.The following minimal example defines a toy backup function wrapping the
cp
command and using a templated output for the target file. The code works fine on the task alone, but fails when wrapped with a worfklow with:future: <Task finished name='Task-2' coro=<ConcurrentFuturesWorker.exec_as_coro() done, defined at .../pydra/engine/workers.py:169> exception=Exception("target_file has to be str or bool, but LF('backup', 'target_file') set")>
I would expect both runs to be successful and yield the same result modulo the temporary directory prefix.
The text was updated successfully, but these errors were encountered: