Use pyodk for ODK Central API calls

[spwoodcock]

• We manage calls to the ODK Central API using the requests library.
• ODK released pyodk a year ago & in theory it should track any future updates to the API.

The question is: should we use pyodk instead of managing this ourselves in OdkCentral.py?

This could be implemented alongside #206 if we decide to go that route.

[robsavoye]

OdkClient.py pre-dates pyodk,but offers slightly different functionality. Also osm-fieldwork has the odk_client program, which offers a command line interface which I use frequently. I haven't looked at pyodk for a while, but it was lacking functionality FMTM needs, and the only command line utility was unmaintained.

[spwoodcock]

Good point that osm-fieldwork is both a CLI and an API, while pyodk is mostly just an API.

I don't think pyodk could replace osm-fieldwork by any means, but could be integrated to replace the calls to Central.

pyodk handles requests sessions nicely, has built in error handling, plus in theory should be up to date with all of the endpoints available in Central.

So we could replace the endpoint calls we need for specific use cases, plus could also expose all of Central's endpoints quite easily via odk_client.py as a CLI.

[robsavoye]

OdkCentral.py is just one program in osm-fieldwork. :-) It has been handling requests nicely, so why replace it ? If OdkCentral.py was missing and endpoint, for example entities and dataset support, that would be a reason to use pyodk in addition to OdkCentral.py.

[spwoodcock]

(put this in main thread for clarity)

On second thought, it's probably not worth the hassle.

We would have to wrap each pyodk call we need in a method of OdkClient or OdkUser anyway, so it doesn't really reduce maintenance.

We already handle session pooling, so the only advantage I see is perhaps better error handling of failed responses from Central.

If we don't need Entity/Dataset endpoints either, then this probably doesn't make sense.

[robsavoye]

Improving error handling of central errors would not be much work. Refactoring to use pyodk would be quite a bit of work, and there are higher priority issues to work on.