python-http / discussions

Public discussions for the Python HTTP Working Group

discussions

Public discussions for the Python HTTP Working Group

discussions's Issues

Moving hstspreload package under the organization

@kislyuk has shared the name hstspreload on PyPI with me and I've revamped the project to be more efficient (not loading the whole list into memory to do lookups) and to automatically deploy new versions when the Chromium HSTS Preload list is updated.

What are everyone's thoughts on moving the project under this organization?

https://github.com/sethmlarson/hstspreload
https://pypi.org/project/hstspreload

Ownership of requests, requests3

So, this: not-kennethreitz/team#21

I've proposed python-http for requests - can put together something more significant as a proposal if we want to go for that.

I've also proposed that I'd like to take admin over requests3. (Not as a decision on "that's what I think http3 should end up as", but so that we have it as an open option.)

How will funding be structured?

So, whenever we start making a song & dance about "python-http" I think we'll obvs want to have a good plan in place for how we'd like to approach funding for the project space as a whole.

My initial thoughts here would be that I'd probably want to try to run something like Encode's existing funding approach. Either paying into the PSF, and managed via contracts through them, or into Encode OSS Ltd, and managed through there.

Personally I'm a bit wary of third parties trying to buy their way into acting as middlemen. Dealing with the necessary Stripe integration etc. is something I'm already doing with https://fund.django-rest-framework.org/topics/funding/ so setting up a more direct sponsor/project relationship makes sense from my POV.

Some questions here include "who's time do we need to be paying for if we can raise funding", "what org is managing the funding", and "are we taking a per-project approach, or something more general".

I nearly have enough funding income to support my own time, so, while I need to try to make sure that's secure my priorities would prob lean towards something like a part-time internship for a community manager, who (amongst other stuff) could take on incoming tickets, and help reduce the overall weight of work.

Alternatively, if there are particular tranches of work that need funding, then that's another option. (E.g. time for folks on developing HTTP/3 stuff, or time on bringing the http3 work to completion.)

How can we be collaborating better?

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. encode/httpx#768 python-trio/hip#124 (comment))
• Talking through what specfic API or technical differences we believe there are between hip and httpx with 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?

Naming for HTTP3 / Next-Gen HTTP client library

NOTE: This discussion started within Team discussion before it was pointed out that the public could not see the discussion thread

This is a continuation of the discussion under python-http/python-http.org#3 about the naming for http3. There's also a good amount of public discussion on this issue on the http3 project.

To summarize those discussions the names that are candidates in any way are:

• http3 (Current name, confusing to users/common acronym conflict, especially if we don't support HTTP/3 right out the gate, is an acronym)
• https (Common acronym conflict, name we already have)
• hyper (Great name, currently an unmaintained but semi-frequently downloaded project by @Lukasa, name collision with python-hyper)
• fetch (Kinda related to HTTP, probably could grab from PyPI)
• requests3 (Lots of baggage, limits some design decisions)
• httpx

Make a logo for python-http

Published IRL for URL parsing

NOTE: This discussion started within Team discussion before it was pointed out that the public could not see the discussion thread

Would love some eyes on and thoughts about irl which is essentially urllib3's URL parser in it's own tiny library. Was in the middle of refactoring to remove the rfc3986 dependency from urllib3 due to it's slow import time and wanted to make the work available for others (including http3) to use.

Maintaining requests

Kenneth has transferred the Requests repo to the PSF: https://github.com/psf/requests

This is a major change for the project and the Python community as a whole, and I think a positive one that a lot of us are excited about. But it leaves a lot of details to work out! So here's a thread where we can discuss what happens next, and a few questions to get us started:

Interested parties

• The Python HTTP working group, which we're still getting set up. For those who aren't aware, this was @theacodes's idea to form an umbrella to try to coordinate efforts across projects and with the PSF (though Thea, you don't seem to be a member of the org – is that intentional?). There's an overview here.

• The PSF: CC @ewdurbin

• The Requests maintainers: IIUC, right now this is basically just @nateprewitt?

Is there anyone else who should be CC'ed?

What's the goal?

I'm pretty sure that the folks who've been involved in the python-http group discussions so far are all interested in seeing Requests become a regular community-maintained open-source project, with oversight and fiscal sponsorship from the PSF, and are eager to help make that happen.

Ernest, what's the PSF's plan for handling its new project?

Nate, what are you thinking? I don't know if you were even involved in any of this discussion so far, despite being the main maintainer for the last few years...

Transfer logistics

As far as I know, the Requests project's main assets are:

• The repo and issue tracker: now held by the PSF
• The requests name on PyPI: according to PyPI's database, this is owned by @nateprewitt, Cory Benfield, and Ian Stapledon Cordasco. IIUC, Cory and Ian are actually retired from involvement with the project (which is why I haven't @'ed them). So really just Nate in practice.
• The python-requests.org domain name. Does anyone know who owns this currently? This is an actual legal asset, and one of the major purposes of the PSF is to hold onto those, so ideally that's where it would end up, but I don't know if anyone is working to make that happen...

WSGI & ASGI docs.

Prompted by this comment on twitter... https://twitter.com/GrahamDumpleton/status/1232180616663187457

Having a community-owned space hosting the WSGI and ASGI docs repos might not be a bad idea if there's any motivation, if Graham and Andrew were keen, and if establishing if a "Python HTTP Working Group" is still something that we'd collectively like to pursue?

Which repositories will live under the python-http organization?

What are our thoughts on this org. wrt project repositories?

Should we be considering having http3 (under whatever actual branding) live under this org?
Same question for h2/h11 and similar projects?