-
Notifications
You must be signed in to change notification settings - Fork 732
Generate plugin schema #6361
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
base: master
Are you sure you want to change the base?
Generate plugin schema #6361
Conversation
✅ Deploy Preview for nextflow-docs-staging canceled.
|
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.
Does not look to have dependency with the nextflow runtime, does it? could make sense to keep it in its own module or even keep it in the gradle plugin source? it would be preferable to have the gradle plugin to no depend on the main nextflow runtime
The Long-term, I think we'll want to have a module in Nextflow that defines a versioned "runtime API" that is stable across Nextflow versions. For now I'm just trying to make it work |
e2cf820
to
ec096ff
Compare
ec096ff
to
b5f5437
Compare
Signed-off-by: Ben Sherman <[email protected]>
b5f5437
to
dff137f
Compare
|
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.
Let's use YYYYMMDD
as prefix
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.
Would not make sense to create a JSON schema for the definition spec? it could be used to have more a "formal" definition and above all to validate it in the upload
"spec": { | ||
"name": "hello", | ||
"description": "The `hello` scope controls the behavior of the `nf-hello` plugin.", | ||
"children": { |
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.
This is essentially a non-basic type, would not make sense to call it 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.
Not sure what you mean by this
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 mean object
instead of children
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.
The properties here are based on the domain classes in SchemaNode
Okay I have written a JSON schema for plugin "specs" We need to store this schema somewhere on GitHub so that a plugin spec can refer to it, for example: {
"$schema": "https://raw.githubusercontent.com/nextflow-io/nextflow/master/plugin_schema.json",
"definitions": [
// ...
]
} We should probably keep it in a separate repo since it is not tied to the Nextflow version. We could extend https://github.com/nextflow-io/schema-spec to include both input/output schemas and plugin schemas |
This PR adds an entrypoint for generating a "plugin index file", which contains a list of plugin definitions (config scopes, functions, etc).
It should be used by the Nextflow Gradle plugin to generate the index file when building/releasing a plugin, and it should be consumed by the plugin registry for use by the language server, registry UI, etc.