I'm curious to see how the limitation of using pyodide packages only will play out for non-trivial builds. Thinking of all the non-pure python code out there that need to be manually rebuilt to support a non-trivial production app.
Maybe Cloudflare's adoption will help bring more packages into the fold, and if it's an 80/20 rule here, would be good enough.
I certainly think there's an 80/20 rule here. Most packages are not very hard to port, and generally the ones that are hard to build use features like threads and multiprocessing, graphics cards, raw sockets, green threads, or other capabilities that have no obvious analogue in a webassembly runtime.
As we mention in the blog post, the biggest issues are around supporting server and request packages since they are clearly useful in cloudflare workers but are difficult to port because they frequently use raw sockets and some form of concurrency.
As we build out support for some of these features in the Workers Runtime, we should be able to port Python modules to use them. Some features like raw sockets are already available, so we should be able to make some quick headway here.
(Myself and Hood above are the folks who implemented Python Workers)
Maybe Cloudflare's adoption will help bring more packages into the fold, and if it's an 80/20 rule here, would be good enough.