Update
Hey everyone. I received a lot of supportive comments from people, and for that I’m very grateful. Unfortunately, all of the comments took some version of the form of “I’d be happy to contribute some, but I don’t have the time to run the project”. To be clear, I think this is a perfectly sensible answer, after all it is basically my answer here. However I’m really not looking for contributors, I’m looking to be done with this project. Also, the more I’ve looked at the project, the more I think it has certain fatal flaws in its approach, and the right course of action isn’t to keep pushing forward in this direction but rather find a new one.
Thus, my current inclination is to simply deprecate ExAws entirely, and advocate that someone write a replacement.
A replacement could utilize the patterns in ExAws that I think are good, while also aiming to auto-generate functionality as people tend to do in other languages with AWS libraries. The bits that are worth keeping from an approach perspective is:
- Pluggable dependencies (minimize hard coded deps on any specific json codec / http library / etc).
- Operations as data structures. Instead of
Aws.S3.list_objectsactually doing the request, have it return a data structure that you pass to a function that actually executes it. This allows much much easier interop with other libraries.
Areas where a new library could improve:
- Utilize auto-generated functions from the spec to get 100% API coverage immediately
- Testing strategy. I never came up with a good way to do tests in ExAws and consequently there basically aren’t any. This is bad for all of the obvious reasons, and it’s also a key element of why development stagnated. I had to manually audit or test every change since there wasn’t any regression testing, and as I ran out of time that meant I either had to blindly merge PRs or not merge PRs at all. I chose the latter generally, and this killed the project.
