-
Notifications
You must be signed in to change notification settings - Fork 7
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
input fastq.gz #28
Comments
This is something that's on my todo list for a while. It's complicated by the fact that not all tools accept fq.gz files, which therefore requires the tool wrappers to detect fq.gz inputs, know whether the tool supports that, and decompress if required. It's very doable but a significant chunk of work to ensure it all works seamlessly so it may take a while before I can release a new version with this functionality. |
do you think that might be somehow easier to make a check at the very beginning of the pipeline and if the input is gz is unpacked and saved in a temporary file then eventually deleted? HTH |
That's a possibility, although one reason I haven't already implemented this is that it's easy to run into a situation where the uncompressed versions of the file are deleted but then further processing is required. Because symbolic links are used throughout the pipeline it's easy to run into situations where those links break, requiring detection of the problem, then re-decompression of the input files to fix. At the end of the day, it still needs some thought to manage this in the best way, and it's pretty easy to decompress the file manually upfront. |
Hi,
is it possible to make rampart handling input fastq.gz adding a check and eventually do an automatic gunzip?
The text was updated successfully, but these errors were encountered: