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

What should our API at the command line look like? #1178

Closed
heuermh opened this issue Sep 20, 2016 · 1 comment
Closed

What should our API at the command line look like? #1178

heuermh opened this issue Sep 20, 2016 · 1 comment
Labels

Comments

@heuermh
Copy link
Member

@heuermh heuermh commented Sep 20, 2016

With transformFormats in 8cec2c0, we introduced a single CLI command that helps both ways, in that it transforms from native formats to ADAM Parquet and vice versa.

Looking at our current list of commands, perhaps we should extend this pattern

adam2fasta
adam2fastq
adam2vcf
allelecount
anno2adam
count_contig_kmers
count_kmers
depth
fasta2adam
flagstat
flatten
fragments2reads
listdict
mergeShards
print
reads2coverage
reads2fragments
transform
transformFeatures
vcf2adam
view
wigfix2bed

Taking it to the extreme (where all the conversion operations fit under a single transform command) is going too far; I'm looking for a nice balance.

We could also take this opportunity to make sure all the commands and command line arguments are named consistently (e.g. camelCase vs. snake_case vs. whatever-you-call-it-with-dashes).

@fnothaft
Copy link
Member

@fnothaft fnothaft commented Mar 3, 2017

I think this has substantial overlap with #1327; I'm going to close in favor of the other ticket, as it is more actionable. @heuermh please reopen if you disagree.

@fnothaft fnothaft closed this Mar 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.