-
Notifications
You must be signed in to change notification settings - Fork 714
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
Migration to topic channels #4517
Comments
Just to reiterate what I said there, it seems |
Yeah these will just be used for the versions files (though maybe we can start adding a multiqc topic channel 👀) |
I had a demo of a proposed methodology for using the topic channels for this here; https://github.com/stevekm/nextflow-demos/tree/master/topic-channels-versions additionally, I am working on a Nextflow plugin that will be able to directly convert the topic channel versions outputs to the MultiQC Software Versions table. So we could skip the individual versions-YAML files and go directly to the final MultiQC table. Also I had a Discussion here about standardizations for the schema of the topic channels to be used for this if we had a standardized schema to use for "versions" then it would be easier for everyone to align on consistent handling methods. In particular, I wanted to start including the "container" in the versions output, I am not sure that its currently being captured in the legacy versions YAML format also there was a related issue here nextflow-io/nextflow#4934 |
Plan after discussion with @mashehu and @mirpedrol:
This way we can progressively switch to the new Same with |
Should also consider other usage of topic channels whilst we're here. One that springs to mind is outputs for MultiQC. These are often emitted from many processes and collected at the end in a similar way to versions. Could have a |
Starting an issue to track. Probably gonna need a hackathon for this 🙃
docs
Tasks
The text was updated successfully, but these errors were encountered: