Ah

You can specify it in the config

Can I also downgrade my version of Nextflow?

Yeah or use

NXF_SYNTAX_PARSER=v1

but I'd rather you update to nf-schema 2.7.1 to be safe 😁

Yeah this is for a paper so rather not have hacks, I'll downgrade to 25.10 for this purpose 🙂

Also fine 😛

oh last version is 2.7.2 sorry 😛

The new schema breaks due to strict parsing due to casting thing.

params

that are supposed to be integer like

params.foo = 10

are passed as strings to the pipeline at runtime. It requires to define them

as Integer

in the main workflow to restore the functionality. Where is the best way to define this if there are too many

params

like this?

I don't mind compiling the source code since the automatic downloading is not working, but the README does not have any instructions for the compilation.

@Nicolas Vannieuwkerke is there an option for conditional validation? We have this PR that strips out a lot of useful functionality https://github.com/nf-core/sarek/pull/2184 reason being that the snpeff and vep cache buckets are not available in all CEs AND the tools are not run on the

test

profile, so it validates sth that doesn't need validating. Basically if we could run the validation only if tools.contains('vep') that would be ideal

Probably a stupid question, but I just upgraded to 26.04.3 and getting:

Unrecognized config option 'validation.defaultIgnoreParams'

IS that to be expected? Or did I mess up the latest template merge?

Ignore me, I forgot to update the plugin version!

After upgrading #C02FC6VFQG1 to nf-schema 2.7.2 I get this error:

ERROR ~ Argument of `file()` function cannot be empty

 -- Check script 'subworkflows/nf-core/utils_nfschema_plugin/main.nf' at line: 72 or see '.nextflow.log' file for more details

Line 72 is the call to

validateParams

in:

if(validate_params) {
        validateOptions = [:]
        if(parameters_schema) {
            validateOptions << [parametersSchema: parameters_schema]
        }
        if(cli_typecast != null) {
            validateOptions << [cliTypecast: cli_typecast]
        }
        validateParameters(validateOptions)
    }

I call the utility function like this from the local subworkflow:

UTILS_NFSCHEMA_PLUGIN (
        workflow,
        validate_params,
        null,
        help,
        help_full,
        show_hidden,
        before_text,
        after_text,
        command,
        null
    )

I.e. with

null

for

parameters_schema

. A couple of

println

shows that neither of the two `if`s are visited, and

validateOptions

is

[:]

when the function is called. Running the pipeline with

--help

works. Tools version 4.0.2, fails both with Nextflow 26.4.03 and 25.10.4. Doing the same with #C01U1E95JQ5 just works. I can't find any differences between the two.

What is the correct way to set a string default that is clearly empty? I used to use

[]

but after a schema update this seems to be no longer valid

I posted a question regarding lamdas in e.g. samplesheets in #C02L5UB4Y9G earlier, but I suppose this is the place: The below wouldn't work, right?

sample,fastq_1,fastq_2
arc00,{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates00_1.fastq.gz' },{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates00_2.fastq.gz' }
arc01,{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates01_1.fastq.gz' },{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates01_2.fastq.gz' }
arc02,{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates02_1.fastq.gz' },{ params.pipelines_testdata_base_path + 'testdata/archaeal_duplicates02_2.fastq.gz' }

I.e., there's no way around needing to hardcode GitHub urls in test sample sheets? Which means that I have to update them before doing a PR to nf-core's repo from my fork?

Anyone around for a quick review? github.com/nextflow-io/nf-schema/pull/215

One more very small PR before the release: github.com/nextflow-io/nf-schema/pull/216

<!here> version 2.7.3 has just been released! The main new feature is the ability to mask certain strings from the parameter summary (implemented by @Michael Heuer). See the full changelog for all changes.

Can I get a review on this PR migrating tests to strict syntax: github.com/nextflow-io/nf-schema/pull/212

I'm working on a first implementation of the

samplesheetToRecords

function which will convert a samplesheet to a list of Record types. However while doing this I'm also finding myself at the point where I need to decide how we want to use record types (especially with the meta map). So my question is: What would you prefer? (please react with the emoji) Option 1️⃣ : All values will be available as a key-value pair in the Record, meaning that meta field and input field will be on the same level. (TBH this is my preferred way of working with records as this allow directly joining on specific meta keys using the

join

operator without having to do any preprocessing of the channel structure). Example:

[[id:'test', single_end:false], test_R1.fastq.gz, test_R2.fastq.gz]

Would become:

record(id: 'test', single_end:false, fastq_1:test_R1.fastq.gz, fastq_2:test_R2.fastq.gz)

Option 2️⃣ : We keep a

meta

key in the record that contains all meta values. (This would keep our channel structures relatively the same as before) Example:

[[id:'test', single_end:false], test_R1.fastq.gz, test_R2.fastq.gz]

Would become:

record(meta:[id:'test', single_end:false], fastq_1:test_R1.fastq.gz, fastq_2:test_R2.fastq.gz)

Option 3️⃣ : If you have a better idea please post it in this thread!

<!here> nf-schema 2.8.0 has just released! This version contains a change to the pattern validation of proxy filesystems (thanks to @Robrecht Cannoodt) and a fix for azure files being validated as directories (thanks to @Adam Talbot). See the full changelog for details: github.com/nextflow-io/nf-schema/…/2.8.0

Anyone around for a quick review? github.com/nextflow-io/nf-schema/pull/221

I got another PR ready: github.com/nextflow-io/nf-schema/pull/220. It looks big but is mostly the removal of a feature and a version bump (version 3.0.0 is coming 👀). Anyone free to take a look?

A smaller PR this time, but with more breaking changes 🙈 : github.com/nextflow-io/nf-schema/pull/222

I got some efficiency updates ready especially for large samplesheets and schemas: github.com/nextflow-io/nf-schema/pull/223

A new feature in nf-schema for parameter substitution in samplesheets. I think this is the last PR before the big 3.0.0 release excited dog : github.com/nextflow-io/nf-schema/pull/225

<!here> Great news! Version 3.0.0 of nf-schema has just been released! This version does contain some breaking changes so be sure to check out the migration guide on how to properly migrate your pipelines. Here are some highlights from this release: 🔄 Added a new option to allow parameter substitution in samplesheets ❌ Removed support for help message creation via configuration options (the options are still there but they change the way how the `paramsHelp()`function works 🚄 Improved the efficiency of the samplesheet parsing code Updated the input structure of some functions to have more consistency See the full changelog for all details: github.com/nextflow-io/nf-schema/…/3.0.0

Hi, I would like to clarify something regarding nf-schema defaults. I am allowing parameters via samplesheet, or params. The idea is that samplesheet should take priority, but if the param is not set per-sample there should be a fallback to the param. Here is what I am doing

channel.fromList(samplesheetToList(params.input, "assets/schema_input.json"))
        /*
        This is a somewhat crucial step, where the samplesheet and params are used to determine per-sample parameters.
        This has been greatly simplified thanks to @nvnieuwk
        */
        .map { it ->
            def meta = it[0]
            // Populate everything that has no value with the value from params
            return meta.collectEntries { key, val -> key == "group" ? [ key, val ] : [ key, val ?: params.get(key) ] }
        }

1. However, I also set

defaults

in

schema_inputs

. As I understand, this probably breaks what I want to do, and I should rather remove the defaults from the schema, to ensure that this actually falls back to params? To do this: should I remove defaults? Will I still receive an entry if there is no default and it was not in the samplesheet? Should I set defaults to

null

? 2. Something about this that has been bothering me for a while is: I assume that if a user were to set a

param.something = true

and in the samplesheet would provide

something

as

false

, this would actually override the per-sample value false with the param value true, because

val ?: params.get(key)

would get it from params, since the condition is false. Is there some established pattern to handle this?

Coupla nf-schema additions from my exploration of Nextflow's bleeding edge: • github.com/nextflow-io/nf-schema/pull/230 (channel params) • github.com/nextflow-io/nf-schema/pull/232 (schemas in pipeline composition)