Repository navigation
How can we be collaborating better? #9
Description
Having finally come through the requests transfer to the PSF, and having set up a Python HTTP organisation, I think we'd all been hoping that we'd be in a position where we're all working together as "team Python", on improving the state of HTTP in Python, and working collectively in the interests of the community.
That's come somewhat unstuck lately, since we've got two independent streams of work on a high-level client library, with both the hip and httpx teams working on addressing the same space.
I'd really like to try to find some constructive ways for us to move towards a more collaborative approach, but it's not clear to me what needs to change in order to be able to do that.
The sorts of things I'd hope we might be able to start working towards include:
- Thinking about moving core HTTP components into python-http, and having them collectively under a shared governance.
- Considering if there's a core interface we could settle on as a point of API seperation between the client layer and the network layer. (eg. Transport API encode/httpx#768 Notes on "high-level" HTTP support python-trio/hip#124 (comment))
- Talking through what specfic API or technical differences we believe there are between
hipandhttpxwith a view towards figuring out if we can be better aligned.
I think it'd be hugely beneficial for the community if we could find a way to reconcile some of these issues.
If we're presenting a unified, community focused approach I think it'd also put the Python HTTP organisation in a really strong position to start thinking about launching a sponsorship program. Personally I could see that as something along the lines of how Django REST framework approachs this, but with substantially higher tier rates, and with the funds taken directly by the PSF, that can then independently assess how best to contract out maintainence or feature work for projects within python-http.
There's obviously been a huge issue in the past in the way that requests has been the public face of Python HTTP, and has been in a position of undue influence, while relying on urllib3 as it's core component, so a more collective approach that benefits and empowers folks working across the entire stack feels important.
Thoughts?
Activity
florimondmanca commentedon Jan 30, 2020
I've been meaning to leave a longer-form comment here, but at least let's jot some thoughts down.
Overall I am convinced there are ways we can make this work, i.e. bring more collaboration between the HTTPX and
hipteams.There's a ton of useful info/ideas present in python-trio/hip#124, and I think the practical suggestion/migration path of splitting HTTPX between the client-side and the network-side in encode/httpx#768 (comment) are very much worth taking note of as well.
I believe we can transcend the question of "who should be the high-level, public API, and who should be delegated to a backend provider library?". There's definitely ground for building something new, i.e. breaking away from past dynamics we've seen between Requests and urllib3.
It seems we all wish to settle down on "so what is the interface we could use to draw the line between client/session-side, and dispatcher/transport side?". For example:
hip: Notes on "high-level" HTTP support python-trio/hip#124 (comment) (and somewhere else I believe, but I couldn't find it back)I think we can say that on the HTTPX side we'd be more than happy to work together towards drawing that line. So what about the
hipteam? cc'ing @njsmith @sethmlarson @pquentin (anyone else?).As a final note, perhaps a first step for concrete collaboration would be to open a discussion on "so what should the dispatcher/HTTP transport API look like", here.