pip can't run inside of Pyodide because it needs to do stuff like make requests
that don't work inside the virtual environment. So the virtual environment bin
folder contains a python-host executable which is a symlink to the
sys.executable that created the virtual environment. The shebang for pip uses
python-host. But then when pip installs an executable it uses sys.executable to
create the shebang for the installed executable. If that is python-host then the
installed executable will run outside of Pyodide. So we need to patch
`sys.executable` to point to the Pyodide Python.
This switches to passing the source and build directories as arguments.
It adds an output-directory argument to pyodide build allowing us to
indicate where the output wheel should go independent of the build
directory. I also did some cleanup of the logic added in #3310
This is a followup to #3740 which rearranges the logic a bit more on further consideration.
I found out that if you create a revocable Proxy and then revoke it, a huge number of browser
internal operations raise TypeErrors. Such an object is thus an excellent stress test for our
handling of explosive objects. Overall we do quite well, `isPyProxy` and `compute_type_flags`
are actually the only spots where we run into trouble (and `PyProxy_Check` is the only spot
that is raising a fatal error).
This changes it so that an object with a `length` getter that throws an error or returns
not an integer will have a `__len__` in Python that always throws an error. It can't check
the type anymore because it avoids invoking getters so if the result is a return value from
a getter it won't know the type. The same is true for the `Error.name`, `Error.message`, and
`Error.stack` fields.
To check for methods, I still use `typeof x[method] === "function"`, invoking the getter.
Usually functions don't have getters anyways and I think it is weirder to have false positives
in this case. If there is a getter and it raises an error, we catch it and throw it away.
This fixes a regression introduced in #3283.
To be properly paranoid we should assume that each property access can raise an error.
If an error is raised, throw it away and don't set the flag.
This could be further improved to avoid some getter calls but this a start.
I'm running into a crash in cibuildwheel where some of its CI environments don't set HOME. This fixes set_build_environment to be a bit more resistant against crashes due to missing environment variables.
Add sourmash (Python + Rust extension, packaged with maturin) and missing pure-wheel deps (screed, bitstring, cachetools, deprecation).
After a couple of fixes in sourmash-bio/sourmash#2433 I managed to build it out-of-tree, would like to have it available here to make it easier to distribute (while PyPI doesn't support emscripten wheels).
Resolves#3717.
Before:
```js
$ tstate = pyodide._module._PyEval_SaveThread()
$ pyodide.globals.get("x")
Pyodide has suffered a fatal error. Please report this to the Pyodide maintainers.
The cause of the fatal error was:
RuntimeError: memory access out of bounds
```
After:
```js
$ tstate = pyodide._module._PyEval_SaveThread()
$ pyodide.globals.get("x")
Uncaught NoGilError: Attempted to use PyProxy when Python GIL not held
```
v0.23.0 changed which binary files are needed (removed pyodide_py.tar and pyodide.asm.data and added python_stdlib.zip). The old files were removed from the exports but the new file was not added to the exports.
Bart Broere