Implement optional and default_value for workflow input parameters.

[jmchilton]

#8232 + transforming workflow state for the tool form client.

[mvdbeek]

I like this a lot, but we should fix the default values that are selected without user intervention (i.e define a required integer parameter in the workflow editor, it shouldn't default to '0' in the workflow run form imo).

I started working on this in mvdbeek@04c555d but I still need to wrap my head around how we forward invalid parameter selections in the regular tool form and why you can only create a non-optional IntegerToolParameter with a valid value.

If you can drop the debug statements (assuming they are just for debugging) I'm happy to merge and build on this.

[mvdbeek]

why you can only create a non-optional IntegerToolParameter with a valid value.

I guess that's just what we say in the schema: https://docs.galaxyproject.org/en/latest/dev/schema.html#id24

If false, parameter must have a value. Defaults to "false".

I do feel like that's a weird choice for a mandatory workflow integer parameter though, but maybe I'm wrong.

[jmchilton]

I should have taken a pass at cleaning up the debug (prints, unneeded try/excpt, etc..) - sorry @mvdbeek. I'll rebase with a cleaning up of all of this - I'll eliminate that extra str cast as well and see if that was important.

[jmchilton]

I'm well on the record that the tool state interactions are absolutely the most terrifying part of Galaxy in terms of long term technical viability. I'm in no rush to push something through that complicates things and leaves them in a partially implemented state. This can wait for us to implement (or leverage) the concept of "a required value without a default" so we can look at things all together and make judgements.

Frankly - I'm uncomfortable with merging this without implementing optional data inputs at the same time 🤷‍♂.

[mvdbeek]

This can wait for us to implement (or leverage) the concept of "a required value without a default"

We should line out what that would involve and look like. Would this be another attribute on parameters such as no_default_value="true", or would we just do what we do for optional parameters, but raise an exception when attempting to execute the tool if no value has been chosen (and have the tool form highlight that parameter in some way) ?
What you're worried about is having a tool state (let's say an integer parameter) in the database that doesn't have a value, and it'd be difficult to know if that's legitimately without value ?

[jmchilton]

Would this be another attribute on parameters such as no_default_value="true", or would we just do what we do for optional parameters, but raise an exception when attempting to execute the tool if no value has been chosen (and have the tool form highlight that parameter in some way) ?

I don't know - either seems fine to me. Whatever is cleanest?

What you're worried about is having a tool state (let's say an integer parameter) in the database that doesn't have a value, and it'd be difficult to know if that's legitimately without value ?

I'm just worried about more crazy paths through basic.py frankly. This state thing though seems to be a legitimate concern - especially for executed tools - but hopefully we'd catch this problem before getting that far.

[martenson]

this is now in conflict, please resolve it

[jmchilton]

Closing in favor of #8807. Applying the workflow module interface changes to a second application clears up I think what I stumbled into here...