Open charlesreid1 opened 6 years ago
Leaning more strongly toward item number 1 above (defining default parameter sets in a directory of default parameter sets) rather than item number 3 (
My reasoning is, (I think) we want the default parameter sets to be easy to "discover", duplicate, modify, become a changing component. Putting them into the rules portion of the workflow (which is generally not touched by the user) means they will also not be touched by the user.
(Of course, if that's what we're after - authoritative default parameter set values that the user should not touch - then Option 3 would be better.)
Point of clarification: when I said "Workflow authors have one and only one way to define sets of workflow defaults", I realize this makes it sound like we have to choose from the above options. That's not what I meant - above items cover both the user side and the developer side. We want there to be one way for the developer to specify default parameter sets. We would like to have one or more ways for the user to specify default parameter sets.
+1 to number 1!
Multiple ways to do this.
Workflow author provides the user with a ready-to-go sets of parameters labeled (e.g.,
hard-params.json
,medium-params.json
,soft-params.json
)User specifies a parameter set on the command line, like
% taco workflow1 --medium ...
(not sure how different from 1) in the .settings file of each workflow, the workflow author provides the user with a set of ready to go sets of parameters that are labeled as, e.g.,
hard_cfg
,med_cfg
, andsoft_cfg
that utilize the same mechanism to define a default but would offer multiple defaults.These approaches all seem to share in common the idea that the workflow author is going to provide a set of defaults. The user can request those defaults in a number of different ways, but we should follow the principles: