Open AlexVCaron opened 4 months ago
Neuroimaging modules and subworkflows in nf-core will live aside of the nf-core directories
To clarify, this was a solution that I pitched as a first iteration, still need buy-in from more of @nf-core/core. I think this is a great start to the conversation.
I think the aside sounds like it's not a part of nf-core, which is not the intent. I think the issue is that putting it in the nf-core directory, the neuroimaging
could get lost.
I've changed my stance. I think the better, easier solution due to the technical limitations and why we have the redundant nf-core
directory. modules/nf-core/neuroimaging/denoising/nlmeans/
should work with the current infrastructure.
more background discussion happened, and modules/nf-core/scil/denoising_nlmeans
is the currently preferred path
Does this modules/nf-core/scil/denoising_nlmeans
work? I would expect issues with the _
in the module name since various parts of the tools
code make assumptions about splitting on _
(in the module name) and the fact that there can be only a max-depth of 2 (tool/subtool) for a given module.
If this works I am interested because many modules would have their name readability improved by the addition of _
Description of feature
As discussed with @edmundmiller and the infrastructure team at the Boston Hackathon 2024.
Neuroimaging
modules and subworkflows in nf-core will live aside of thenf-core
directories, inmodules/neuroimaging
andsubworkflows/neuroimaging
. However, the current framework doesn't support it, tools need to be adapted for modules and subworkflows.Here is a (non-exhaustive yet) list of potential problems :
org_path
in.nf-core.yml
org_path
in.nf-core.yml
A good use-case of this is the first neuroimaging PR nf-core/modules#5673 . An equivalent of the modules in that PR are also in nf-scil. There the tests and linting passes (we did many changes on our end to do so); they are a good reference.