I've dropped a package for anyone wanting to test this out on my personal apache space.
They are signed with my PGP key as usual. pip install -e http://people.apache.org/~anthonyshaw/libcloud/1.0.0-rc2-requests/apache-libcloud-1.0.0-rc2-requests.zip@feature#egg=apache-libcloud The hashes are on the space http://people.apache.org/~anthonyshaw/libcloud/1.0.0-rc2-requests/ Anthony On Mon, Apr 4, 2016 at 11:22 PM, Markos Gogoulos <[email protected]> wrote: > I don't think I will have the time during this week to test this, would > just like to say a big 'Bravo' for this work! > > > > On Mon, Apr 4, 2016 at 1:27 PM, anthony shaw <[email protected]> > wrote: > >> 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 >>
