Summary lib function prints false as different to the schema when no default

[ewels]

The NfcoreSchema lib function params_summary_map prints quite a lot of values for the summary when they do not vary from the schema.

• If a parameter in nextflow.config is set to null or false and the pipeline schema does not have a default parameter set
• All memory and time units (string representation output is different to schema)

Example output from the nf-core/methylseq pipeline using -profile test:

------------------------------------------------------
                                        ,--./,-.
        ___     __   __   __   ___     /,-._.--~'
  |\ | |__  __ /  ` /  \ |__) |__         }  {
  | \| |       \__, \__/ |  \ |___     \`-._,-`-,
                                        `._,._,'
  nf-core/methylseq v1.6
------------------------------------------------------

Core Nextflow options
    runName                        : awesome_minsky
    containerEngine                : docker
    container                      : nfcore/methylseq:1.6
    launchDir                      : /Users/ewels/GitHub/nf-core/methylseq/testing
    workDir                        : /Users/ewels/GitHub/nf-core/methylseq/testing/work
    projectDir                     : /Users/ewels/GitHub/nf-core/methylseq
    userName                       : ewels
    profile                        : test,docker
    configFiles                    : /Users/ewels/GitHub/nf-core/methylseq/nextflow.config

Input/output options
    input                          : null
    single_end                     : true
    email                          : false

Reference genome options
    genome                         : false
    fasta                          : https://github.com/nf-core/test-datasets/raw/methylseq/reference/genome.fa
    fasta_index                    : https://github.com/nf-core/test-datasets/raw/methylseq/reference/genome.fa.fai
    bismark_index                  : false
    bwa_meth_index                 : false

Bismark options
    meth_cutoff                    : false
    known_splices                  : false
    minins                         : false
    maxins                         : false
    bismark_align_cpu_per_multicore: null
    bismark_align_mem_per_multicore: null

Generic options
    email_on_fail                  : false
    max_multiqc_email_size         : 25 MB
    multiqc_config                 : false

Max job request options
    max_cpus                       : 2
    max_memory                     : 6 GB
    max_time                       : 2d

Institutional config options
    config_profile_name            : Test profile
    config_profile_description     : Minimal test dataset to check pipeline function
    config_profile_contact         : false
    config_profile_url             : false
    project                        : false
    cluster_options                : false

[Only displaying parameters that differ from pipeline default]
------------------------------------------------------

I think that a lot of this is is because the schema default for strings is set to an empty string if it is not set:

tools/nf_core/pipeline-template/lib/NfcoreSchema.groovy

Lines 509 to 518 in d0a6649

	if (schema_value == null) {
	if (param_type == 'boolean') {
	schema_value = false
	}
	if (param_type == 'string') {
	schema_value = ''
	}
	if (param_type == 'integer') {
	schema_value = 0
	}

This then means that the default doesn't match it in this block:

tools/nf_core/pipeline-template/lib/NfcoreSchema.groovy

Lines 538 to 540 in d0a6649

	if (params_value != schema_value) {
	sub_params.put("$param", params_value)
	}

I wonder if we should just delete the first block (I don't think that should break anything, right?) and standardise that unset parameters should be defined as null in nextflow.config. I had a discussion with @drpatelh in Slack about this the other day I think too.

For the memory & time, I wonder if we just try and parse all strings as memory / time units - if it succeeds for both the param and the default we can save them as the correct unit and the default matching should work.

[ewels]

This could also be linked to #976, in that the problem is that params that don't have a default value are handled as always being different to the initialised config param.