Hi author of xo! It is really a great library, and many designs of dgw is inspired by xo! And, yeah, I still think it is possible to contribute/extend xo, and would love to do it. However, since our project needs composite primary key/autogenerat key compatible SQL so badly, I created my own repo to just solve our problems. Plus, it was difficult to unit test xo, since it doesn't have *_test.go file at the moment.
This tool is yet another auto-rebuild-reloader for go net/http. I had been using fresh, but development of this tool got really inactive from middle of the last year. So, I decided to rewrite from the ground up, adding more flexibility by using toml configuration file, making it possible to use gb or gom to biuld binary, adding bunch of tests, and keeping code structure simple so that it will be easy to contribute.
This tool was built by just spending 5 hours of my weekend, and not really sophisticated at this stage, so pull-requests and issue reports are all very welcomed :)
However, our usecase just needed HipChat V2 room notification API + Python3 compatible HipChat client, which can only send messages to the specified room if a room token is given, without needing an admin token. (Admin token could be pretty dangerous and certainly unnecessary in this case.)
This library is designed to do simple thing simple with minimum sysadmin concern.
Yeah, you are right. It is perfectly possible to wrap awscli by shell script and do exactly the same thing with what this tool does. However, generally speaking, it will be more and more difficult to test and maintain as a tool becomes large, especially if it's written in shell script. Python has awesome testing library (I love py.test), and the most importantly, has really cool AWS mock library moto (https://github.com/spulec/moto). These are pretty much why I picked Python, rather than bash alias or shell script for this tool.
I know awscli is trying to use skelton JSON to save keystrokes, and it certainly helps a lot of adhoc operations to be done quickly without spending precious cognitive load. I use JSON parameter template in my shell script, but feel like it is not for "command line tool". It is just my feeling, but still hard to neglect since I'm really used to UNIX-like command line tool.
Thank you for your comment! It really helps me to keep moving on! If you find any issue or space for improvement, please let me know, since the software is just borned a couple days ago!
I love boto, but when I filed the issue and received the answer from a committer, I decided to move to boto3. I can understand the situation but, boto seems to be be strictly backward compatible. So let's move on to boto3 and have nice Resource API with all AWS services.
Thanks for the comment! Yeah, I hear you. awscli is really awesome tool, but when it comes to day-to-day/adhoc operations, it doesn't do well like Unix tools. And that is exactly why I wrote this!
awscli is by far the most comprehensive CLI tool manipulating various AWS services, and I really like its flexible options and up-to-date release cycle. However, day-to-day AWS operations from my terminal don't need that much flexibility and that many services. Rather, I wanted just small set of UNIX-like commands which are easy to use and remember. So I wrote this small Python package.
If you are interested, please let me hear what you think!