New container decorator

[elliotgunton]

Pull Request Checklist

• Fixes HEP0001 - new container decorator #1065
• Tests added
• Documentation/examples added
• Good commit messages and/or PR title

Description of PR
Adds the container decorator, and the special path function on Outputs

[sambhav]

Not sure if I like this pattern of doing if template.

[elliotgunton]

I don't love it but it was the best I could find for linter/developer sanity - magically adding the arg in the decorator is a bit too opaque even for devs IMO

[sambhav]

@elliotgunton how about instead of using template, we can use the function itself?

def my_container(my_args:...):
    my_container.<attribute>

[elliotgunton]

@samj1912 is there a sensible way to add container_call_wrapper.template = container_template as a type-hintable attribute to the function? (From some searching it seems not)

Otherwise I don't think it's a nice user experience. For the template: Optional[Container] = None argument to the function, in terms of user experience it at least kind of acts as an explicit opt-in for advanced users, who would probably prefer nice code completion over nice syntax. (If we can add type hints to the function attribute then I'm 100% for it!)

Another idea is some global value that we can set before calling the user function?

from hera.workflows import current_template  # no idea on naming 😅

@w.container(command=["sh", "-c"])
def advanced_hello_world(my_input: MyInput) -> MyOutput:
    output: MyOutput = MyOutput(container_greeting=f"Hello {my_input.user}")
    current_template.args = [f"echo Hello {my_input.user} | tee {output.path(output.container_greeting)}"]
    return output

[flaviuvadan]

impl wise this looks good to me. We already chatted about the user experience in one of the maintainer syncs. Anything else to review @elliotgunton? Happy to approve bc it lgtm!

[sambhav]

I would prefer to go back to the drawing board for this specific feature as I'm not sure of the UX it promotes. Happy to release the other parts that are already merged. We barely use container templates in Hera anyway compared to scripts.

[elliotgunton]

@samj1912 I'm not sure there is a better balance of UX for the "advanced container" use case from the proposal, as the proposal itself broke the paradigm of config-as-code (contained within type signatures etc), instead running the function to create the container config/spec. I can remove the code for the advanced use case if the basic one is fine?

[sambhav]

Sure, let's start with that

[sambhav]

@elliotgunton if it's simple, can we also extend this to other template types?

[elliotgunton]

@samj1912 as in stubbing the function for inputs/outputs? Yes that should be okay. I'll make a new issue for it

[sambhav]

@elliotgunton Yes, given a template being able to set its properties in the decorator and the i/o in the signature.