check_requirements() answers "can this install in the browser?" for each name it is given, and only for those names. It does not look at what those packages depend on.
So a model that is itself a pure-Python wheel passes the check even when one of its dependencies has no wasm-compatible wheel. The failure then surfaces where the check was meant to prevent it: in the reader's browser, after a successful build.
$ artesian check mymodel
ok mymodel 0.3.1 has a pure-Python wheel
...while mymodel depends on something with only manylinux wheels that Pyodide does not bundle.
Possible approaches
- Read each distribution's
requires_dist from the PyPI JSON already being fetched, and walk it, reporting the tree rather than a flat list. Needs cycle handling and environment-marker evaluation (extra ==, python_version), so it is not a two-line change.
- Or: state the limitation in the report output, so the flat list does not read as a clean bill of health.
The second is cheap and honest and could land first.
🤖 Generated with Claude Code
check_requirements()answers "can this install in the browser?" for each name it is given, and only for those names. It does not look at what those packages depend on.So a model that is itself a pure-Python wheel passes the check even when one of its dependencies has no wasm-compatible wheel. The failure then surfaces where the check was meant to prevent it: in the reader's browser, after a successful build.
...while
mymodeldepends on something with onlymanylinuxwheels that Pyodide does not bundle.Possible approaches
requires_distfrom the PyPI JSON already being fetched, and walk it, reporting the tree rather than a flat list. Needs cycle handling and environment-marker evaluation (extra ==,python_version), so it is not a two-line change.The second is cheap and honest and could land first.
🤖 Generated with Claude Code