-
Notifications
You must be signed in to change notification settings - Fork 737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add schema to validate meta.ymls #2913
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good :)
We will still have the problem of "wrong" indentation. When the indentation is not wrong but not in the way we like, this makes the command nf-core modules info
fail. For example:
- html:
type: file
description: FastQC report
pattern: "*_{fastqc.html}"
instead of
- html:
type: file
description: FastQC report
pattern: "*_{fastqc.html}"
I tried it out and my schema checker complains correctly about it (but doesn't fix it automatically, we still need to do that by ourselves). |
I tested this pre-commit hook with Gitpod and did not fail, but now having a look at the follow up PR nf-core/tools#2190 I see that the linting complains :) |
Yep, that is working as expected. Or were you thinking of something else? |
No, works very nice 😄 |
ah, you meant the git-hook doesn't do anything? let me check. |
Could we also add a line to all the meta yamls with something like this ---
# yaml-language-server: $schema=https://path-to-schema.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good but I would rather make it more strict 😬
yaml-schema.json
Outdated
"properties": { | ||
"type": { | ||
"type": "string", | ||
"description": "Type of the input channel" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we set an enum based on: https://nf-co.re/docs/contributing/modules#documentation point 6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(applies to output: too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added it now locally and I get quite a few deviations. Because I see quite a lot of "list" entries coming up, should we add it to the options? (if that is the correct groovy data object)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather say list
isn't so informative for the type, it's the contents of the list is more important (is it a list of files?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would opt for getting rid of list
and just specifying the type of the list elements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is important to indicate if it is more then one item, so I would go for nested here, so we can actually check the items themselves as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But shouldn't that be inthe description (that's normally how I do it)
type: file
description: A file or list of files that XYZ
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we make it nested, we could then for example check the file extension of each individual file. More validation power 🦾
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍝
}, | ||
"licence": { | ||
"type": ["array", "string"], | ||
"description": "Licence of the tool", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe an enum using: http://bio-tools.github.io/biotoolsSchema/#Link21 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that list is a bit too long and would make the schema quite unwieldy I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought with JSON schema you can refer to 'remote' enums? But agree wouldn't want to embed the whole list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder how bioconda/conda does it 🤔 as they have a lint for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, true! will try that
# Conflicts: # modules/nf-core/cellranger/mkgtf/meta.yml
In order to avoid this I am proposing the following JSON-schema. We will use this then during
nf-core modules lint
to check the meta.ymls (and in the future also for subworkflows). It also is integrated in the pre-commit check. If you are using the yaml extension for VS code you get also hints about expected entries when working on this file (by adding the following to your settings.json