The goal of this PR is to reduce the dependency on pyodide for testing pyodide-build. The main changes are:
1. Add a new fixture: `mock_emscripten` for mocking emscripten compiler toolchain. This fixture will create a dummy emcc (+ other toolchains) to the PATH. When running tests, all emcc calls will be intercepted by this command.
2. Improve `xbuildenv` fixture. Previously, this fixture actually created an xbuildenv from the Pyodide artifacts. So, we had to have Pyodide already built before running the tests. In this PR, this fixture now uses a pre-built minimum xbuildenv.
As a result, now all tests in `pyodide-build` run without building Pyodide. The only exception is `test_xbuildenv_create` which test `pyodide xbuildenv create` command. In a follow-up, I am planning to migrate the `provide venv` tests, which are in `test_cmdline_runner.py.`
I updated the platform when we build with build-recipes but not with pyodide
build. This also updates the platform tag for wheels produced with pyodide
build.
This swaps out the build backend of pyodide-build for hatchling, which is
simpler and faster.
The difference in the SDists: This removes the zip directories entries,
setup.cfg, and .egg-info directory and contents. It includes the .gitignore,
since hatchling uses that to decide what to include by default.
The difference in the wheel built from the SDist: The useless top_level.txt is
gone and the license is in the licenses directory.
This should restore support for `pipx run pyodide-build` instead of
`pipx run --spec pyodide-build pyodide` by teaching pipx about the primary entry
point in the package.
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
This adds Lakers (`lakers-python` on PyPI), the Python wrappers for the Rust
implementation of EDHOC (RFC9528). EDHOC is a compact key exchange protocol,
primarily designed for embedded systems.
As a compiled package it can not use the pure Python wheels published through
crates.io. It is useful in pyodide because aiocoap has [good support for pyodide
and Jupyter](https://aiocoap.readthedocs.io/en/latest/pyodide.html) for
end-to-end encryption between a browser console (or application) and an embedded
device (connected through untrusted proxies on the Internet or through local
Bluetooth connections). I expect to add EDHOC support to aiocoap through lakers.
This adds some basic ability to snapshot after executing user code. It is pretty
brittle right now:
1. It will crash if the user loads any binary extensions before taking the
snapshot
2. It doesn't track changes to the file system
Snapshots will probably have to be experimental for quite a while.
1. I think I have a pretty good solution for this, which I will work on in a
followup.
2. One possibility here is we could serialize the entire filesystem state into
the memory snapshot. This would be hard and make the snapshot big, but we
wouldn't have to load python_stdlib.zip when restoring from a snapshot so it
probably wouldn't increase the total download size by much...
We've gotten a lot of complaints about how hard it is to call certain JS
functions, but it's hard to do much to improve the situation without knowing
anything about the specific function being called.
However, if we know about the API, we can choose how to convert to/from JS as
appropriate and make things a lot easier. This adds a method to JsProxy called
`bind_sig` which adjusts how __getattr__ and __call__ work on the proxy so we
can choose our converters. I added a class called JsSignature which
guides what we do when we call the function. I completely rewrote
JsProxy_Vectorcall to use this. I added handling for Promise results so we can
automatically bind a signature to the result of the Promise.
There's a lot leftover to do:
* Generator and AsyncGenerator types
* Alternatives A | B (try A converter and if it raises a TypeError fall back to B)
* TypedDict converters
* Make calling certain objects call `Reflect.construct`
* Cleaner __getattr__ handling, __setattr__ handling
* A way to raise AttributeError if the attribute is missing from the signature
even if it's present in the JS object (important for backwards compatibility)
* Signatures for JS stdlib functions
My idea is that the signatures should simultaneously function as mypy typehints
as much as this is practical.
This pulls in the newest commits of sphinx-js that can render type aliases and
interfaces into the docs. I used it to add documentation for `PackageType` and
`PackageData`. It also adds type params in the signature line of js functions,
which I'm actually not sure is that great since the signature line otherwise has
no types.
This pulls in the tip of the master branch of sphinx-js and shortens the
jsdoc.py patches by about 60 lines.
I also fixed some broken links and various typedoc and sphinx warnings.
I turned on nitpicky mode and silenced intentionally broken links so in the
future we can catch broken xrefs better. These warnings also help turn up
cases where private fields are accidentally included into the docs.
I renamed module.ts to emscriptenSettings.ts which is more descriptive. Rather
than setting a bunch of the settings fields from pyodide.ts, set them in
createSettings. I also marked all these fields as readonly so typescript can
help us ensure that they are set up correctly in createSettings and not edited
from pyodide.ts.
I changed most of the functions in `emscriptenSettings.ts` to return a
`PreRunFunc` rather than taking the settings as an argument and mutating it.
I also removed the `moduleLoaded` `postRun` hook, I believe that it hasn't
been needed for a long time.
In Emscripten v3.1.58, createPyodideModule returns a distinct object from its argument
so if we confuse EmscriptenSettings with the instantiated module, we'll get problems.
This fixes these problems.
I also added some more type declarations.
Split from #4715.
For CoolProp, we are getting `tarballname` as `'CoolProp_sources.zip?viasf=1'` which then
crashes when we give it to `shutil.unpack_archive` with `Unknown archive format`.
Since we renamed `syncify` the method name `callSyncifying` doesn't make much
sense anymore. It is implemented in terms of a so-called `promising` wasm call,
so `callPromising` lines up with that. Not a perfect name, but it is rarely used so it
will do until we come up with something better.
Added a `callWithOptions` function. We now have three boolean parameters for
a Js-to-Python call:
1. kwargs
2. promising
3. relaxed
So we'd need 8 functions to cover all combinations of these. Currently we only
have 6 of these. Rather than adding the two remaining combinations which will
have annoying names, I added `callWithOptions` which takes an options argument as
the first argument. Despite the fact that options usually go as the last
argument, I think it makes sense to use the first argument for this so that all
remaining args are passed on to Python.
Hood Chatham