Raised by @Joon-Klaps reviewing #75 (#75 (comment)): should --refseqfile (and by extension other input files) support compressed input, e.g. .gz/.xz?
Currently isFastaFile() in workflows/phyloplace.nf, added in #75, reads the first line of --refseqfile directly via path.withReader to sniff whether it's FASTA (for the embedded-taxonomy fallback from #66). A gzip/xz-compressed file wouldn't be detected as FASTA this way -- it would silently be treated as "not FASTA" rather than erroring, since the raw compressed bytes don't start with >.
More broadly, several other pipeline inputs (queryseqfile, refphylogeny, hmmfile, taxonomy) aren't checked for compressed variants either, and whether/how each downstream tool (HMMER, Clustal Omega, EPA-NG, gappa, the new custom/resolvetaxonomy module) handles compressed input varies.
Worth scoping as its own piece of work rather than folding into #75: decide which inputs should support compression, verify each downstream tool's actual behavior with compressed input (don't assume), and add explicit decompression where a tool can't read it natively directly in the module that needs it (matching the pattern used elsewhere in this pipeline of decompressing inside the module rather than via a separate bridging module).
Raised by @Joon-Klaps reviewing #75 (#75 (comment)): should
--refseqfile(and by extension other input files) support compressed input, e.g..gz/.xz?Currently
isFastaFile()inworkflows/phyloplace.nf, added in #75, reads the first line of--refseqfiledirectly viapath.withReaderto sniff whether it's FASTA (for the embedded-taxonomy fallback from #66). A gzip/xz-compressed file wouldn't be detected as FASTA this way -- it would silently be treated as "not FASTA" rather than erroring, since the raw compressed bytes don't start with>.More broadly, several other pipeline inputs (
queryseqfile,refphylogeny,hmmfile,taxonomy) aren't checked for compressed variants either, and whether/how each downstream tool (HMMER, Clustal Omega, EPA-NG, gappa, the newcustom/resolvetaxonomymodule) handles compressed input varies.Worth scoping as its own piece of work rather than folding into #75: decide which inputs should support compression, verify each downstream tool's actual behavior with compressed input (don't assume), and add explicit decompression where a tool can't read it natively directly in the module that needs it (matching the pattern used elsewhere in this pipeline of decompressing inside the module rather than via a separate bridging module).