broadinstitute/warp-tools

This repository contains all containers that WARP uses.

warp-tools's Issues

split TagSort away from fastqpreprocessing (in directory structure)

As of #6 , TagSort is now completely decoupled from the fastqpreprocessing code - the .cc/.h files and Makefile rules they're compiled from are entirely disjoint. So it should be seamless to move TagSort out of warp-tools/fastqpreprocessing, into a new warp-tools/TagSort directory.

An alternative (if wanting to keep tools of the same pipeline together) would be to rename the fastqpreprocessing directory to indicate there are two tools in it. However, having the directory structure make clear that there are no dependencies between the two to worry about is a valuable complexity reduction, one that is reliable and lasting compared to a handful of people temporarily "knowing" that it is the case. So keeping them together should look like warp-tools/some_new_name/TagSort and warp-tools/some_new_name/fastqpreprocessing.

outdated "develop" branch set to default

I cloned the repo just now, and was confused to find the changes from #6 - which github showed as merged - not existing. It turned out that there is a custom "develop" branch that is set to be the default. This is a problem, because "develop" is currently behind master.

AFAICT the "develop" branch is intended as a staging area, I think for full-on end-to-end tests involving building a Docker image and everything. If possible to do that sort of thing directly on the branches that PRs are created off of, then that would be cleaner: the feature branch is going to exist anyways, so the "develop" setup is just adding the complexity of an extra step in the process of submitting+deploying code.

If there is something more essential about the "develop" setup that I am missing, then automation is required to make this behind-master situation impossible.

TagSort should be able to output BAM

The usage of TagSort that actually produces a sorted version of the input file (as opposed to just being used to compute metrics) writes a tab-separated ASCII SAM file. TagSort's input is a binary BAM. Since the point of BAM is to save space, and the point of TagSort being C++ is to handle huge data efficiently, it seems likely that someone using sorting feature might prefer BAM output.

It's also possible just converting from SAM to BAM after TagSort is done would work well enough to not justify the additional work this would take.