Add native support for multiple org_path in modules and subworkflows directories

[AlexVCaron]

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 the nf-core directories, in modules/neuroimaging and subworkflows/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 :

• Linting and testing locally is not possible without changing org_path in .nf-core.yml
• Installation in pipelines is not possible without changing org_path in .nf-core.yml
• Lint and test checks fail since they cannot discover the modules and subworkflows correctly (names are not mangled correctly since they don't contain nf-core)

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.

[edmundmiller]

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.

[mashehu]

more background discussion happened, and modules/nf-core/scil/denoising_nlmeans is the currently preferred path

[awgymer]

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 _