Skip to content
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

Open
5 tasks
Tracked by #5828
edmundmiller opened this issue Nov 30, 2023 · 7 comments
Open
5 tasks
Tracked by #5828

Migration to topic channels #4517

edmundmiller opened this issue Nov 30, 2023 · 7 comments

Comments

@edmundmiller
Copy link
Contributor

edmundmiller commented Nov 30, 2023

Starting an issue to track. Probably gonna need a hackathon for this 🙃
docs

Tasks

@edmundmiller
Copy link
Contributor Author

@mahesh-panchal
Copy link
Member

Just to reiterate what I said there, it seems topic makes a global queue type channel that can be fed into. It's useful for emitting versions but not for something like emitting say bam and bai files together because of process aliasing, etc.

@edmundmiller
Copy link
Contributor Author

Yeah these will just be used for the versions files (though maybe we can start adding a multiqc topic channel 👀)

@stevekm
Copy link
Contributor

stevekm commented May 22, 2024

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

nextflow-io/nextflow#4925

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

@stevekm
Copy link
Contributor

stevekm commented May 22, 2024

@maxulysse

@ewels
Copy link
Member

ewels commented Jun 27, 2024

Plan after discussion with @mashehu and @mirpedrol:

  • Progressively move to topics, break dependency with Use eval to collect version #5834
  • Use a topic name versions_file with old versions.yml path output style
  • Use a topic name versions for a new eval syntax
  • Have pipeline-level logic to load the old files and process into a string that matches the new eval syntax
  • Pipeline logic to take the new style strings and generate the required YAML files for reporting

This way we can progressively switch to the new eval syntax in modules, which will be a rather large and manual effort.

Same with topics - the old channels will remain for now with the same channel names, so the old syntax should continue to work.

@ewels
Copy link
Member

ewels commented Jun 27, 2024

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 multiqc topic for any outputs that should be used for that purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants