Open cthoyt opened 2 years ago
Hey @cthoyt I took a look at ontoportal-client
and it seems like it could drop in pretty easily. I did notice that there was a recent change to make the client name a class variable. It turns out I think that would actually help make the integration into OAK a bit easier. Wondering if you have plans to make a release with those changes any time in the near future?
Yes I can drop a release anytime, it’s quite easy with the Tox configuration
Here's a draft PR: https://github.com/INCATools/ontology-access-kit/pull/204 (still have some tests to fix!)
Having the name
class variable would just simply this bit here. OntoPortalInterface
could use that name for the API key lookup instead of having implementation classes define it in addition to the OntoPortalClient
class to use.
It's a fairly minor difference so if you want to make a release I'll gladly pick up the new version, otherwise I don't see much harm in updating it later.
thanks!
reopening as we still only using the inner layer of ontoportal-client (the bit that returns json).
there is still more to be done to move some parts of oaklib.impl.ontoportal into ontoportal-client, see:
https://github.com/cthoyt/ontoportal-client/issues/3
but if you like you can reclose this and open more specific issues, e.g for different components like annotator/search/ancestors
I have previous written a harness for accessing the API for OntoPortal instances in the Bioregistry project. I spun that code out into a clean project at https://github.com/cthoyt/ontoportal-client. I'd be happy to move that to a different namespace if other people want to contribute to it.