Active development, making library async compatible, client agnostic etc.
johtso opened this issue · comments
Just wanted to create a bit of a point of discussion regarding "the big picture".
It would seem that @ionrock doesn't have masses of time to spend on this project at the moment. It works great, and a lot of people use it. Smaller changes are being merged but the occasional burst of more extensive input / PRs by contributors tend to fizzle out. This is totally understandable. But would be great if this energy could be put to use!
At the end of last year I got excited about httpx and decided I wanted to try and port this library to work with it. I then got larger aspirations and decided to try and separate the caching logic from the IO following the sans-io philosophy (and therefor also the requests specific stuff). This would mean it could have a transport for requests and a transport for httpx, and would also be fully asyncio compatible.
To be honest it was more a bit of fun than anything, but I had a bee in my bonnet and got it working, with the full test suite passing, sync and async. The caching policy is implemented as a coroutine, which seemed a pretty neat abstraction at the time. It works with async, but there's only an in-memory cache backend at the moment. Other backends could be added with full asyncio compatibility which would be cool!
I guess the big question is, is there enough interest / energy out there to make something happen.
My vision would be a httpx/requests agnostic, sync async compatible library. The test suite would be all data in and out of the sans-io protocol, no need for mocking requests etc. (this isn't something I got round to doing but shouldn't be hard to do with the existing test suite).
My fork may or may not be a good starting point! I'm quite happy with it..
I wish I could say I had loads of time and energy to put into something like this, but health issues mean I might not be able to offer much more than discussion and code reviews, and my fork if someone wanted to use it as a starting point. I also hope I'm not treading on any toes, just don't want to see good intentions and code go to waste.
#240
@Flameeyes's large refactor PR (would have based my fork on this if I'd known about it)
#225
#232