Tom Close

I think this is just a case of type-checking uncovering an existing bug. I have run into the missing help_string -> 3rd arg == default issue before and it is...

> @ghisvail @tclose - want to try this before merging? Don't have the time atm, so happy to go with this and find problems later

added "jupyter" install option to pyproject.toml as suggested

Given that inputs are passed to the initialisation of the task in the canonical workflow construction pattern, in order for static type-checkers to follow what is happening, the task inputs...

Here is a prototype with mock classes that works with `mypy` (but not pylance unfortunately) ```python import typing as ty from pathlib import Path import inspect from typing import Any...

You would then define shell specs as psuedo "dataclasses" ```python @shell_task("mycmd") class MyShellCmd(SpecBase["MyShellCmd.Out"]): in_file: File = shell_arg(argstr="", position=0) an_option: str = shell_arg( argstr="--opt", position=-1, help="an option to flag something", converter=str,...

THIS IS OUTDATED, SEE SLIGHTLY UPDATED SYNTAX BELOW, https://github.com/nipype/pydra/issues/670#issuecomment-1663204523 which would be used in a workflow like ```python wf = Workflow(name="myworkflow", input_spec={"in_file": File}) mytask = wf.add(MyFunc(in_int=1, in_str="hi")) mytask2 = wf.add(...

The other main syntax difference to the end user (i.e. non interface designers) is that the function/shell wrappers are separated from the task classes, so they don't return tasks to...

Thanks for the detailed feedback @satra! > @tclose - thank you for all the work you have put into #662 and the thoughts here. this latter issue of wrapping functions...

EDIT: I realised that by splitting parameterisation from configuration, that workflow construction would be creating a light-weight object and `Workflow.add(spec: Spec) -> Node` method call could add a `Node` object,...