[Do not merge!] Pseudo PR for first release

[mashehu]

Do not merge! This is a PR of dev compared to the TEMPLATE branch for whole-pipeline reviewing purposes. Changes should be made to dev and this PR should not be merged! The actual release PR is at

[mashehu]

went through the rest.

• modules need to be split
• more documentation needs to be moved over to nf-core
• nf-core pipelines lint error need to be fixed
• nextflow_schema.json is not valid (please use nf-core schema build to edit it in the future)

[mashehu]

sorry, but we having parameter files linked in an external repo is not really the nf-core way. we prefer to have everything nicely bundled together to avoid version mismatches and keep things reusable.

[quentinblampey]

It's possible to provide all the params directly in the command line, but since there are many parameters I just recommend some "presets" to get started, but it's not mandatory to use these
I think the main problem comes from the parameters nested hierarchy, which doesn't show up on the instruction section of sopa on the nf-core website, although they are documented on the nextflow schema
What's your suggestion?

[mashehu]

if you put this as enums in your nextflow_schema.json you can skip this

[quentinblampey]

I already list the possible options in the nextflow_schema, but here I want to check more complex logic, like here
I don't know how to do such check with a schema, do you know if it's possible?

[mashehu]

do you need this for a 1.0.0 release?

anyway you can also do deprecation with the nextflow_schema.json

[quentinblampey]

It can be useful for Sopa users who were using Snakemake and want to move to nf-core/sopa
They could keep the same parameters and it should work, even though their parameters are one year old

Concerning the schema: is it also possible to handle the deprecation logic as in here? Again, I don't know how to update other parameters of the config directly based on the schema

[quentinblampey]

Thanks @mashehu for the second round of review!

I split the modules as requested and started adding more docs, but I still have a few questions (see my answer to your review above)

Also, when running nf-core pipelines lint, I don’t see any error - I’m using nf-core version 3.3.2. Which error do you see?

Regarding the schema, what’s the right command line to check that it’s valid? I tried nf-core pipelines schema lint and also received a “schema looks valid” result...

[mashehu]

sorry, looks like I linted the wrong version, all good there now concerning linting errors 👍🏻

[quentinblampey]

Hi @mashehu,

I finished including all the details for the technology inputs (instead of pointing to the Sopa docs).

Regarding your last three remaining comments above, I think the last critical one is the one about the "parameters within an external repo".

I thought it was fine like that because I'm just providing example parameters, but any user can still run the pipeline without using the pre-built parameters. One difficulty I have is that it's difficult to provide some default values, because we provide multiple segmentation options, and the best choice may depend on the input technology (for example, for Visium HD we recommend using stardist, while we recommend proseg for Xenium data).

Do you have any opinion or suggestion about it?

[mashehu]

sorry, in the middle of a tools release, so don't have a time to take a deeper look.

I would ask on the pipeline-maintainer slack channel how other people resolved this

[mahesh-panchal]

One difficulty I have is that it's difficult to provide some default values, because we provide multiple segmentation options, and the best choice may depend on the input technology (for example, for Visium HD we recommend using stardist, while we recommend proseg for Xenium data).

Do you have any opinion or suggestion about it?

One way I would suggest is to include config files under the conf folder and dynamically include them based on a parameter.

includeConfig {
    if (params.method == "method1") {
        "conf/method1.config"
    } else if (params.method == "method2") {
        "conf/method2.config"
    } else {
        "/dev/null"
    }
}.call()

This is similar to using config profiles

profiles {
    profile1 {
        includeConfig 'conf/method1.config'
    }
}

The only difference is that profiles can be combined and can overwrite settings of another depending on order.