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
We should make our two main subworflows (GENOME and GENOME_AND_ANNOTATION) into workflows, as it makes more sense for the structure and modularization of the pipeline (we cannot use subworkflows inside subworflows).
For example, as for now, we would not be able to import the BUSCO subworkflow from #77 inside GENOME_AND_ANNOTATION subworkflow.
The text was updated successfully, but these errors were encountered:
I now realise that it is possible to import subworkflows into other subworkflows. I should have said that we 'should not' or 'try to avoid', as I assume it's not good practice, but perhaps I'm wrong?
Either way I think in this case we should have two workflows.
I now realise that it is possible to import subworkflows into other subworkflows. I should have said that we 'should not' or 'try to avoid', as I assume it's not good practice, but perhaps I'm wrong?
Either way I think in this case we should have two workflows.
Good point.
I can't think of a reason why sub-workflows within a local pipeline sub-workflow would be a problem.
For reusable sub-workflows, it is certainly a problem because of version slips. When a nested sub-workflow/module is modified, the only deterrent against breaking the dependent sub-workflow is nf-test tags.
We should make our two main subworflows (
GENOME
andGENOME_AND_ANNOTATION
) into workflows, as it makes more sense for the structure and modularization of the pipeline (we cannot use subworkflows inside subworflows).For example, as for now, we would not be able to import the BUSCO subworkflow from #77 inside
GENOME_AND_ANNOTATION
subworkflow.The text was updated successfully, but these errors were encountered: