Open rth opened 2 years ago
I definitely agree that we need more documentation for the known issues and limitations. Maybe a new documentation page such as Loading Packages > Known Issues / Limitations
would be a good start point?
All of this information should be somehow indicated in
meta.yaml
or possibly a separate markdown file in the package folder.
I'm not sure these are necessary if we add all information in the documentation.
Some more voices in the choir: https://github.com/jupyterlite/jupyterlite/issues/199
A solution we had been thinking about at the UI level: a general purpose message handler which can watch for specific strings (e.g. the pandas one about lzma
) for which we can ship markdown messages to display, and then offer to hide forever.
As documentation technique, potentially moving this content out of the repo:
However they are initially captured, being able to ship them for consumption offline is very useful!
When users load a package/module in WASM VM they expect it to behave strictly identical to how it works with standard Python build.
While among packages that could be used, there are,
re
)numpy
,scipy
)multiprocessing
,sockets
)In general, I think we should better document for each built package what would work and what wouldn't. If we go in the direction of https://github.com/pyodide/pyodide/issues/977 it could be for instance a HTML page per page with some description of what is expected to work and what doesn't. This page could also indicate how much of the original test suite passes.
All of this information should be somehow indicated in
meta.yaml
or possibly a separate markdown file in the package folder.