You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API supports multiple workflow engines per WES server. But in the service info the default_workflow_engine_parameters is just a flat list of dictionaries like this
Does this mean that all engines must support the same set of parameters with the same defaults? Even if these are very different engines like Nextflow, Snakemake and Toil? This would seem little reasonable.
Wouldn't it make sense to either define separate lists of default parameters for different engines (or even versions)? This could be done in a global default_workflow_engine_parameters structure. E.g.
@vinjana another approach that implementations could do is devise their own set of workflow_engine_parameters and map those onto different engines themselves. This does still imply that various engines need to have some sort of property that a given parameter can be mapped to
But since we are starting to have multiple implementations with multiple engines behind the scenes, it is starting to appear that we will need a better strategy for this. I think the second approach you suggest makes a lot of sense. This would allow a way for the API to define the set of parameters that each engine supports independently of each other but also still keep the global default_workflow_engine_parameters and allow the WES api to have it's own set of parameters
The API supports multiple workflow engines per WES server. But in the service info the
default_workflow_engine_parameters
is just a flat list of dictionaries like thisDoes this mean that all engines must support the same set of parameters with the same defaults? Even if these are very different engines like Nextflow, Snakemake and Toil? This would seem little reasonable.
Wouldn't it make sense to either define separate lists of default parameters for different engines (or even versions)? This could be done in a global
default_workflow_engine_parameters
structure. E.g.Or it could be done together with some new definition of
workflow_engines
(following #122):The text was updated successfully, but these errors were encountered: