Convert FASTA_API from SoyBase to Microservice

[ctcncgr]

Convert the fasta-api implementation at, https://github.com/soybase/fasta-api, into a microservice.

[ctcncgr]

@nathanweeks could you build and test fasta_api from, https://github.com/legumeinfo/microservices/tree/fasta_api/fasta_api?

I think I got everything handled and conserved as much of the existing implementation as possible. All of the endpoints should function identically as far as user-land is concerned.

Thanks!

[nathanweeks]

A few initial things:

1. Several additional packages are needed in the requirements.txt: at least fastapi[standard], pysam and (for the venv-based installation shown in the README) setuptools
2. With the latest pysam (0.22.1), the Dockerfile will need ENV CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt due to pysam-developers/pysam issue #1257
3. Not strictly necessary, but it might be helpful to mention docker compose usage in the README.md

[ctcncgr]

Hey All,

Now that were back. Nathan can I get a set of test cases including the ones from the collaborator you had mentioned?

I'll get this setup with some tests and get this into main.

Thanks

[nathanweeks]

Sorry for the delay---how about this to start with?

test.py.txt

A couple tests are commented out: need to find a valid bed file (currently doesn't handle non-standard bed w/ extra column), and the /alignment/count_coverage endpoint response doesn't behave as I would expect?

[ctcncgr]

Thanks Nathan. I'm a bit underwhelmed by the behavior of not handling more than 3 columns in BED. This seems silly because I think "standard" BED really should support at least up to the 9 optional columns that are specified within the BED spec, https://genome.ucsc.edu/FAQ/FAQformat.html#format1

I'll have a look at both the BED stuff and the count_coverage endpoint.

[nathanweeks]

Thanks Nathan. I'm a bit underwhelmed by the behavior of not handling more than 3 columns in BED. This seems silly because I think "standard" BED really should support at least up to the 9 optional columns that are specified within the BED spec, https://genome.ucsc.edu/FAQ/FAQformat.html#format1

I'll have a look at both the BED stuff and the count_coverage endpoint.

My description of the problem was ambiguous at best---the code as-is should handle between 3-9 "standard" BED columns, though it doesn't necessarily handle custom columns (e.g., datastore annotation 7-column BED, where the 7th column is a gene ID of type string instead of the standard BED "thickStart" of type integer).