As per the request of a number of our users, I've been working on a PR to replace the base HTTP connection classes with an implementation using the requests library.
For the following reasons 1. requests is the defacto standard - it would be in the standard library but agreed against to allow it to develop faster https://github.com/kennethreitz/requests/issues/2424 2. it works with python 2.6->3.5 3. Our SSL implementation is bad for Windows users (yes, they do exist!) they have to download a copy of the certificate authority database from some random website, I've seen security people turn to stone whilst reading this 4. Developers can use requests_mock for deeper integration testing 5. less code to maintain The PR is #728 https://github.com/apache/libcloud/pull/728 This started out as what I thought would be a simple change to update LibcloudHTTPSConnection and LibcloudHTTPConnection, after refactoring then I realised the classes were now identical and moved them into 1 instance. There is no longer a need for conn_classes tuple in the Connection class, which is now a conn_class for a single class instance. This change ended up being less about the implementation of the base classes, which was quite simple really, but about updating tests. Aside from the Yak shaving I noticed a few things: 1) the tests were coupled to there being a conn_classes tuple, of the 6300+ tests, I broken 4300 in the first few commits 2) some of the test classes had a method called "respond" and due to Pythons multiple inheritance algorithm this covered the underlying response classes' implementation. 3) Our chunking support mocks for storage tests were designed to always pass, I've implemented a string iterator for the tests, but this still doesn't seem like a fair test So, after updating all of the test classes due to a combination of test fragility, changing the API (and the test mocks making assumptions about the existence and behaviour of internal fields), I now don't have the confidence that a 100% test pass means 0 regression. I think the best approach is not to merge this PR into trunk, but into a seperate branch and allow further testing as a seperate package, e.g. apache-libcloud-requests Please share your thoughts, concerns and ideas Anthony
