Example canonicalization for ConfigWorkflow

[DropD]

This represents the result of steps 4) - 8) in #88 for ConfigWorkflow.

Note how it isolates the tests from syntactic changes in the YAML format, so that only changes in semantics require adapting tests (as I believe they should).

Changes:

• isolate ConfigWorkflow from the need for unit testing by canonicalizing it into CanonicalWorkflow, which can be tested in isolation from the actual YAML format.
• move the dictionary building from a validator in ConfigWorkflow to the canonicalization function
• adapt unit tests

[agoscinski]

In my mind the core.Workflow was the canonicalized version of the workflow and ConfigWorkflow is the python representation of the yaml config with only minimal postprocessing to avoid invalid inputs. I think with time the Config* classes became more distant to the yaml config file. But instead of introducing another level of workflow, I would put the logic that is in the canonicalize_workflow function in the the processing from ConfigWorkflow to core.Workflow. What do you think?

[agoscinski]

This is for the idempotence right? Maybe we then also change the input type data to

Suggested change

	def get_plugin_from_named_base_model(data: dict) -> str:
	if isinstance(data, (ConfigRootTask, ConfigShellTask, ConfigIconTask)):
	return data.plugin
	def get_plugin_from_named_base_model(data: dict | type[ConfigRootTask | ConfigShellTask | ConfigIconTask]) -> str:
	if isinstance(data, (ConfigRootTask, ConfigShellTask, ConfigIconTask)):
	return data.plugin

[DropD]

I will do that, or a version of it that clears when run through mypy.

[leclairm]

In my mind the core.Workflow was the canonicalized version of the workflow and ConfigWorkflow is the python representation of the yaml config with only minimal postprocessing to avoid invalid inputs. I think with time the Config* classes became more distant to the yaml config file. But instead of introducing another level of workflow, I would put the logic that is in the canonicalize_workflow function in the the processing from ConfigWorkflow to core.Workflow. What do you think?

I think there's room for a canonical workflow config in between because core.Workflow already creates the graph with core objects and dependency resolving. What we need are classes between yaml parsing and core objects that remove all ambiguities.

[DropD]

In my mind the core.Workflow was the canonicalized version of the workflow and ConfigWorkflow is the python representation of the yaml config with only minimal postprocessing to avoid invalid inputs. I think with time the Config* classes became more distant to the yaml config file. But instead of introducing another level of workflow, I would put the logic that is in the canonicalize_workflow function in the the processing from ConfigWorkflow to core.Workflow. What do you think?

Remember: my end goal is to separate data cleaning from graph unrolling. It seems you are proposing to tie them together even more.