Change read name to {SRR}.{rid} or {SRR}.{rid}.{sid}

[timoast]

Hi @noamteyssier

Thanks for making this awesome package!

This is a small change in how the reads are named that I found useful for some stuff I've been working on, so I thought I'd open a PR in case you're interested to add this change. Some tools (for example, cellranger) require that read names are matching across the different output files (R1, R2, etc.).

Here I modified the fastq and fasta output so that the reads are named as:

• with --split: {SRR}.{spot_number}
• without --split: {SRR}.{spot_number}.{segment_number} (keep the segment number for interleaved fastq output)

[gemini-code-assist]

Summary of Changes

Hello @timoast, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant improvement to the read naming scheme within the output FASTQ and FASTA files. The primary goal is to standardize read identifiers by prepending the SRR accession, which is crucial for seamless integration with various bioinformatics tools, such as Cell Ranger, that depend on uniform naming conventions across multiple read files. This modification enhances the utility and interoperability of the generated output.

Highlights

• Read Naming Convention: The naming convention for reads in FASTQ and FASTA output files has been updated to include the SRR accession number. This change ensures compatibility with downstream tools that require consistent read names across different output files.
• Conditional Naming: When the --split option is used, reads are named as {SRR}.{spot_number}. Without --split, for interleaved FASTQ output, the naming includes the segment number: {SRR}.{spot_number}.{segment_number}.
• Parameter Propagation: A new accession_prefix parameter has been introduced and propagated through the launch_threads and write_segment_to_buffer_set functions to facilitate the new naming logic in the write_fastq and write_fasta functions.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a useful feature to customize read names in FASTA/FASTQ output by prefixing them with the SRA accession. The implementation is well-structured, passing the necessary options down through the function calls. I've found one area for improvement regarding code duplication in src/dump/utils.rs, where the logic for generating read headers is repeated. Extracting this into a helper function would enhance maintainability. Overall, this is a great addition.

[noamteyssier]

@timoast

Thanks for the PR this is a good addition! I made some small changes to code to split up the tuple in the option and to let users also add in the segment id to their split files (if they want it).

Cheers!