Tools: Have sensible defaults for params.settings.json

[ewels]

At the moment there are quite a few things in this JSON file that we have to add every time by copying and pasting. For example, pattern is required for string types so I ended up pasting "pattern": ".*", a whole bunch of times.

Would be nice to be able to omit these kinds of values and have the code add them in automatically if not present.

Suggested defaults:

"label": "<name>",
"render": "textfield",
"pattern": ".*",
"type": "string",
"default": ""

For other type can have different defaults. For example, boolean could have "default": false if not defined in the JSON.

@sven1103 - does this completely violate the principle of a JSON schema? I'm thinking about this in terms of making it easier to write, but maybe it goes against the principle of the thing... 🤔

[drpatelh]

Is there a way to discriminate between mandatory and optional parameters?

Sent from my Nexus with ignorance.

[ewels]

There is, but I haven’t figured out how to use it yet. We have the required property. But because everything has to have default values, I’m not sure that it actually does anything yet.

[sven1103]

@ewels Because .* is meaningless, you can just omit the pattern property :D I just prepared that field in case once wants to validate a string against a regex pattern. It is not mandatory.

[sven1103]

@drpatelh Yes, it is defined in the JSON schema file: https://nf-co.re/parameters.schema.json.

See the 'required' property under 'definitions'.

[sven1103]

@drpatelh sorry, my answer was actually wrong. If a parameter (not a property) is mandatory, you need to provide required: true in your parameter.json file. It then needs to be checked by downstream code, like nf-core launch. If you want to check parameters against a schema, which are pure JSON objects, you would need a schema for each pipeline, which was not the requirement for this use case yet.

[drpatelh]

Thanks @sven1103. Ok so I now understand the difference between a parameter and its "JSON" properties, and the fact that it's properties need to be checked downstream. I didn't quite get the schema bit but maybe it will make more sense when I see it in action!

[sven1103]

The JSON schema is just a specification of HOW a JSON object and it properties have to look like. In our case I defined the properties of a nf-core parameter object, with name, etc. So you can't provide a JSON file with a parameter object, with a name property of type int, like "name": 1234, because the schema says, it has to be of type string.

So the schema serves as a specification, that other applications can rely on to access parameter objects properties.

[ewels]

@sven1103:

Because .* is meaningless, you can just omit the pattern property :D I just prepared that field in case once wants to validate a string against a regex pattern. It is not mandatory.

...are you sure? This is what I did at first but the validation failed when I tested nf-core launch. So I had to add them in to make it work.

[sven1103]

@ewels yes, I am sure, as the JSON schema is the specification. The issue is my StringValidator implementation:

https://github.com/nf-core/tools/blob/72ff4ed79ee11d36355e0cefd1eea1596516b7a0/nf_core/workflow/validation.py#L116

This should not raise an exception, because from the schema, pattern is not a required property.

[ewels]

I think that this will be solved / no longer relevant with the new approach to JSON Schema.