Open goldingn opened 7 years ago
There's the noprocess
type modules. So seeing them as default args would pretty much sort it.
Doing occurrence and output modules only would be really useful too. Not sure how easy to do though. Again,noprocess
and nomodel
might fix this.
I guess nomodel doesnt exist yet but would need a zoonpredict function that returns na or something.
It think you could make this work. My issue would be that what is returned is not a zoonworkflow object as it does not meet the criteria expected by other functions (such as rerunworkflow). So then these would need to be a different class of object. And now we have a function that returns 2 different types of objects, which might confuse some.
I think I prefer Nick's incomplete workflows which return at the point they end to Tim's noModule fillers. The later feels more like a work around.
When starting an analysis, users often want to visualise occurrence or covariate data before worrying about picking a model etc. I.e. execute only the first couple of steps of a workflow.
One option is to use
LoadModule()
, but that clutters the global environment and might be confusing to new users.An alternative would be to enable
workflow()
to run partial workflows, like this:or this:
or even this:
Modules could only be included in a partial workflow if the module types they depend on are present. I.e. this would be disallowed, as the inputs wouldn't be available:
The underlying machinery shouldn't change much, since returning these partial workflows is what happens when there's an error in a later module.
Thoughts on this interface appreciated.