pyscript: Importing a new package that doesn't exist in `Pyodide`
I have been trying to look into ways to import torch but I couldn’t manage to do so because it isn’t in Pyodide’s list of supported packages.
From my research on this, there are two ways to have any new package be utilized:
- Find a
pure Python 3 wheelwhich means the package could be installed without the need of hard specifications. - Add
torchand its dependencies toPyodide’s list of support packages. This will require doing the following:- Obtaining `Source Distribution of the package.
- Compiling the package locally.
- Building
Pyodidefrom the source. - Add the package to
Pyodide’s list of supported packages by following the documentation - Importing the newer version of
PyodidetoPyscriptI don’t know how this can be done
Questions:
- How can I add a newer version of
Pyodidewhich was built locally toPyscript? - Isn’t there a way to import a python environment that has all of the packages already installed?
- Why do we need to have
pure Python 3 wheel(aka needs to be compiled on all hardware)? Is it because it is actually being compiled on the browser-side which should be able to run all hardware? - From looking into the logs, it seems that every time the page has loaded the packages listed to be used get installed by
micropip, is this correct? If yes, why can’t we store already installed packages to load them? - Why PyScript is super slow? I am assuming this because of the installation of packages from scratch (if my assumption is true).
Relevant resource:
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 6
- Comments: 20 (13 by maintainers)
hi, i am excited to see your interest in this project. 😃
i have been working on getting torch into Pyodide. it’s pretty challenging.
we do have a alpha workflow to get non-pure python packages with c/c++/cython extensions into the pyscript/Pyodide ecosystem, but torch is extra complicated.
i plan on posting the build process for non-pure python packages as soon as i can
There was a discussion about JAX in https://github.com/pyodide/pyodide/issues/2198, tensorflow in https://github.com/pyodide/pyodide/issues/50 and torch in https://github.com/pyodide/pyodide/issues/1625. It would be great to have them but they are all fairly large and complex packages, so it would take a lot of work to make that happen.
For ML wrapping JS libraries (such as ONNX Runtime Web, Tensorflow.js etc) from Python via the Pyodide’s FFI is indeed another solution. Though your API is then not going to be exactly the same as when using e.g. Tensorflow from Python, so one cannot reuse code without changes.
Packages that don’t have pure Python wheels,
setup.pywith setuptools which currently doesn’t work due to unsupported features in the browser https://github.com/pyodide/pyodide/issues/1501We have added a FAQ entry recently on what to do when a package fails to install https://pyodide.org/en/latest/usage/faq.html#micropip-can-t-find-a-pure-python-wheel
Yes, they will be re-installed each time. However the browser would cache them, so they don’t have to be re-downloaded and it’s mostly a matter of unzipping them to the virtual file system (which is fast) and pre-loading dynamic libraries contained in the package (see below).
Yes, in particular for packages included in Pyodide we unvendor tests, so they are a bit smaller. Otherwise, for pure Python packages, there is little difference from where to install them.
If you profile a typical Python application say that loads pandas results would be roughly the following:
A large part of the time would be spent compiling .wasm code objects by the browser. This situation is made worse by the fact that we cannot load dynamic libraries synchronously on demand when Python modules are imported and have to-preload/compile all the libraries in a package when the package is loaded. Libraries such as numpy, pandas etc have a lot of binary extensions which take a while to compile (the same goes for CPython itself). Some browsers would cache WASM compilation https://v8.dev/blog/wasm-code-caching but it’s a step that takes a while the first time. There is active work happening on how to reduce load time in Pyodide but it’s still a challenging topic.
Yep, ONNX web runtime, tfjs-tflite, etc. are fine for inference - but JAX/torch/tensorflow can do much more than model inference. It would be a dream come true to be able to play with JAX’s auto-differentiation in the browser!
@verhulstm I’m super excited to hear about the progress you make on torch and tensorflow. Even more exciting from my perspective would be JAX. Are you working on this in a public repo? I’d love to follow along and help where I can.
currently, you should be able to use all the packages here
https://github.com/pyodide/pyodide/tree/main/packages
you can build your own packages and add them into pyscript. but some packages are very difficult to build. torch and tensorflow are hard to build into WASM and the WASM compiler tooling. i am working on porting torch now and tensorflow after that. i hope to make some new posts as i progress on this task.
Joining late to the party… a bunch of the questions in the original post was already addressed so I’ll focus on the ones that I think were left out:
Currently, you can’t. Opened #172 to address this
I think the question here means to load a packaged “bundle” with pyodide and all (and only) applications require packages once. Right? If so, no, this is not possible today. This is actually an upstream issue that we recently discussed with the pyodide team and we have some ideas on… but not in the short term. /cc @rth
Not entirely sure I understand question but, in any way I could interpret it, it is an upstream question. @rth @hoodmane do you want to chime in?
From looking into the logs, it seems that every time the page has loaded the packages listed to be used get installed by micropip, is this correct? If yes, why can’t we store already installed packages to load them?
If the packages are already included in Pyodide, it will only load them and not fetch them from PyPI and install them. I’d think it’s to optimize size and performance (the more you load/add the bigger and slower it is).
Why PyScript is super slow? I am assuming this because of the installation of packages from scratch (if my assumption is true).
We are trying to investigate in the next few days but it’s very very likely to be an upstream issue.
Thank you for the questions! As we roll out better documentation, we’ll add some of these to the FAQ. 👍
closing as upstream, seems that questions have been answered and there’s not much else to do. Happy to be convinced otherwise 😃
great, i would love to chat in the next few days. email me 😃
Thanks @verhulstm and @sudomaze!
if you have a pure python file that should already work. include a link to the file in your “py-env” tag