This a a great example of good work getting 'upstreamed.' The go-to solution for using requests and urllib3 in the browser had been Koen Vossen's 'pyodide-http' package, which you'd install in PyScript/Pyodide and then call 'pyodide_http.patch_all()`. It monkey-patched requests and urllib3 to use the browser API's. [1]
Then 'pyodide-http' got adopted into the Pyodide-included packages[2], so you didn't have to specify it for install, just import it and run patch_all().
And now a similar technique has been incorporated directly into urllib3. (Not a direct port - as far as I know Joe Marshall and others did a full reimplementation so that urllib3's API's would be maintained as much as possible). [2]
Very cool.
Edit: Looks like there's a note to this same effect on Seth Larson's post about urllib3's future. [3]
Incredible! Two years ago I was experimenting in porting some code at the company I was at to python in the browser (instead of QT desktop apps) and this was the biggest thing I had to work around! I had to manually monkey patch or proxy a few libraries to make them work, but I'll have to test out this update and see if everything magically works
Oh wow, thanks for this story! Would love to hear more if you have time :) Good luck with testing it out.
Note that we found an issue w/ emitting an InsecureRequestWarning by default. The request is perfectly secure, it's just we aren't telling the ConnectionPool that information (see: https://github.com/urllib3/urllib3/issues/3331)
Since this is using fetch/XHR under the hood, I guess requests from the browser are restricted only to same-origin URLs or servers responding with permissive CORS headers?
Lead maintainer of urllib3 here: We're tracking all the options for how we can make the experience better for folks looking to use Python in the browser. Today our biggest blocker is that there's no socket or TLS APIs for Emscripten/WASI. If those were to become available we'd jump on them right away :)
I think the biggest benefit of a foundational project like urllib3 getting browser support is that /many/ Python projects are built on top of urllib3 and many of them likely work in browsers now that urllib3 works in the browser.
For example, Requests is built on top of urllib3 and now gets browser support for free! And this is recursive, how many projects use Requests (spoiler: many). Pretty exciting IMO :)
Thank you for your work on urllib3; I will probably never use Requests if I can help it. I'm glad that you're keeping up that "batteries included" tradition.
wow that's awesome. That we could even talk about potentially using just python to make requests in browser is pretty wild (of course, as you say still blocks in the way - lack of socket or TLS APIs for Emscripten/WASI). Really cool stuff tho. All the best eh and thank you VERY much for the incredible urllib3 library.
Browsers limit the ability for these platforms to use raw sockets, there simply is no API for it. The best that can be done /today/ is to use WebSockets, which are not the same thing and can't be used for HTTP requests without the server expecting a WebSocket connection:
Sure, sorry if it wasn't clear from my question, it wasn't specifically about urllib3, but I meant if there are plans that browsers will make such an API available or if this is something that will never become real.
its udp with encryption and congestion control, but the aspects that gamedevs like about udp, low latency and out of order delivery without head of line blocking are features
except the browser context is being sandboxed with lots of access restriction, individual profiling, geolocation reporting, device identification, and more
Big Tech does not like independent protocol operation it seems; therefore your interesting technical advance is likely to be a pawn in other, larger changes to the social contracts on the open net IMHO
It means that urllib3 (python code) isn't actually making the http request (it's not making the tcp connection, tls auth, writing the request, or serializing the request headers ...)
It may be better to describe this as a "shim". Any python code that depended on urllib3 is now transparently shimmed in browser context to use the fetch-api instead. Which is useful.
This is definitely out of scope for web browsers. The security implications of allowing arbitrary sockets are prohibitive.
To do something like that then you’re going to need a different environment with a different set of security guarantees and expectations, more like a shell where the user is responsible for vouching for the code’s trustworthiness.
The film (especially vfx) industry runs on Python, and so much code is written for Python.
Same reason you'd want to run your server in node.js so it matches your front end code ( and you can reuse code on the front end and backend). Pyscript lets us have the same programming language in the front end and the backend, and access to all of our internal packages on the front end.
A lot of vfx software is written in QT, so at a previous company I actually made a wrapper around a subset of the QT interface and widgets, and replicated it in Pyscript, so we could write an app once and run it from inside vfx applications, or run it in the browser with no additional coding. It wasn't perfect, but it worked and made things simpler
Just joined the discord! I'll also expand on this here though for anybody interested.
We wanted a single library that would allow us to write an app, and either deploy it to employee computers locally (QT, so we could deploy standalone apps or plugins within art applications like Maya, Nuke, or Houdini,) or on the web. We tried JavaScript, but some developers struggled to easily jump over to something like VueJs from Python.
Anyway, what myself and a coworker came up with was just an interface. We already write a lot of PyQT apps, so let's boil that down to the essential features and widgets we use in every app. That means: button, label, text box, drop down, checkbox, radio selection, table. That was the bare minimum to start making functional apps. For layout we needed: vertical layout, horizontal layout, and spacer. With these widgets and layouts, we figured we could recreate 90% of our apps if needed.
This was all very QT inspired. We had events on the widgets that you could register callbacks on. Value getters and setters. The first version was essentially just a barebones wrapper around QT that proxied all of the real QT functionality. It was just QT, but in order to use it you needed to import a different library and things were named slightly differently, and you could only use a small handful of methods and widgets.
After that was when the magic started happening, since "worse QT" isn't a great sell.
Now that we had a very limited subset of widgets, layouts, and methods we were targeting, we could start porting to Pyscript. We wrote a basic example app with all of the widgets, and the goal was "let's figure out a way that we can run this as-is in the browser with no code changes."
We used PyScript, and just rewrote all of those widgets and layouts with the equivalent html+ css + JS. When the developer says `button = Button(label="Click me")`, all that is really doing is making a new button html element. We forwarded important JS events into our library so we could register on-click callbacks. It was all pretty straightforward, only a bit tedious. The hardest part was actually just styling both QT and the HTML elements so they looked the same.
Vertical/Horizontal layouts were just flex boxes. A spacer was just an empty div in that flex box.
On the server side, we had to craft a bit of magic so we could `from my_app import MainWindow` and then `register_window_as_route(MainWindow, "/my_app/")`. A vaguely remember some sort of introspection to see what packages were used by the app, and zip them up for pyscript to import?
And then anything that did web requests was broken. In VFX, almost everybody uses a service called ShotGrid as their database. The ShotGrid API didn't work since it used Urllib3, so we ended up doing some hacky shit to spin up a proxy url on the fastapi server that would actually run the queries and reply with a pickled response. That part was pretty ugly but it worked.
Also threading didn't work in the browser, so we had to monkey patch a few places in our code that tried to use threads
BUT! The end result was we could write basic apps and instantly run them in QT. (the library would automatically detect which "backend" was available between QT and pyscript). With no code changes, we could import that code into our fastapi server and register it on a route, and then pull up the webpage immediately and have all of the same code run in the browser client side.
The code wasn't perfect, there were some spooky corners, but I'm proud of how well it worked from a developer point of view. We could write an app, and then deploy it. We made it a point to have no code changes required wherever possible. We had web apps deployed, and had desktop versions of the same apps ready to go in case the server ever crashed. For a small team at a small company, working on internal tools, it was an incredibly easy and efficient way to work.
Work keeping an eye on Chris Laffra's work in this area - he did a Python in Excel demo [1] a few months back, and while sheets aren't in his ltk framework [2] yet, the work he's done on reactivity-in-python-on-the-web there is really promising.
Then 'pyodide-http' got adopted into the Pyodide-included packages[2], so you didn't have to specify it for install, just import it and run patch_all().
And now a similar technique has been incorporated directly into urllib3. (Not a direct port - as far as I know Joe Marshall and others did a full reimplementation so that urllib3's API's would be maintained as much as possible). [2]
Very cool.
Edit: Looks like there's a note to this same effect on Seth Larson's post about urllib3's future. [3]
[1] https://github.com/koenvo/pyodide-http
[2] https://pyodide.org/en/stable/usage/packages-in-pyodide.html
[3] https://sethmlarson.dev/urllib3-is-fundraising-for-http2-sup...