Are we going to be handling retries? Timeouts?, etc?

The timeout can be adjusted, but if a request fails (timeout or otherwise), we just report failure instead of retrying to avoid requests getting clogged due to records being exported continuously. If we set a timeout, but then retried multiple times, the timeout would no longer limit the time spent attempting to export one set of records. Our reasoning was that missing data is not as bad as delayed data especially in cases of cumulative data where missing data can be interpolated or cases where data is exported on a very short interval. Does not retrying failed requests sound reasonable for this use case?

Depends on how robust we want the functionality of this exporter. We can handle it in a different PR in the future if is needed.

should dependencies be added for python-snappy and requests?

One issue that I am running into is that I cannot add python-snappy to the setup.cfg because it depends on the snappy library in C which I had to brew install to get. Is there a way to add a C dependency that a module requires? If not I might have to specify to first manually install snappy library and module before using exporter in README.

Excluded python-snappy from install-requires for now.

would be good to add the default timeout value to the class documentation

Added, will also add to README

should this be wrapped in a try block?

I did not consider that requests.post could throw exceptions in addition to returning HTTPErrors inside the response. Modified to use a try/except block which handles all request exceptions. (now raises HTTPErrors to be logged as well) This guarantees calling export() will never throw an exception.

Could you update these dependencies to 0.17.dev0 as well as the current version? It's causing some build failures.

Updated