Closed cmungall closed 5 years ago
Lance did start a discussion with me about this. This seems to be a 2 step development activity:
I see you swagger codegenned the main KB API
You could also omit 1, direct coding via the requests library and passing in parameters as dicts is often fine. YMMV
@cmungall yes, @lhannest started working on a generic beacon wrapper here. Lance, where do we sit with that (in this repo's code base)?
@RichardBruskiewich It's finished and ready for use. Maybe a CLI should be added to it as well? It's pretty easy with the click library.
But yes, I think this is a good idea. I would make the aggregator CLI client blocking, but show a progress bar.
progress bar helpful, like the download kind of progress bars (hard to figure out, though, what to provide as a metric of progress in the software....) Maybe, add an optional "timeout" parameter, in case one wants to abort. Also, time taken for a KBA query is probably a function of page size requested (sometimes, page number too?)
+1
On 9 Nov 2018, at 8:32, Lance Hannestad wrote:
@RichardBruskiewich It's finished and ready for use. Maybe a CLI should be added to it as well? It's pretty easy with the click library.
But yes, I think this is a good idea. I would make the aggregator client blocking, but show a progress bar.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/NCATS-Tangerine/beacon-aggregator/issues/86#issuecomment-437415699
This would be useful for ad-hoc exploration. The swagger UI is nice but involves a lot of cut paste.
I am thinking something very simple, no-frills
e.g
not sure how best to deal with async. The CLI could simply be blocking.