- Read the
Instance.rs
documentation to understand how WASM binaries are ported to Python modules viapyo3
Rust crate. - Simply put the workflow looks something like:
- Developer defines Rust functions and compile them via
wasm32-unknown-unknown
target - WASM binary (
.wasm
) is placed in a Python project - With the tools imported via
pip install wasmer
, developer can load the WASM binary and use the exported functions. This way Rust-defined functions can be called transparently from Python. Great Wasmer!
Definitions for snippets below:
- in the context of Python snippets:
module
is the Python module andfunction
is the exported function (exported functions are the ones defined in a Rust library somewhere and compiled to WASM biaries) - in the context of
pyo3
snippets: a Python module is a typePyModule
. It can be declared in different ways
[VERSION 1]
-
- (hide
wasmer
internals) Pythonic imports:
- (hide
from module import function
# `module` should be wasmer Instance and `function`
# should be the exported function
[ADDITION]
-
- (as per 1. plus improve
wasmer
PyModule
) ImplementPyObjectProtocol
for
- (as per 1. plus improve
#[pymodule]
fn wasmer(_py: Python, module: &PyModule) -> PyResult<()> { ... }
In alternative to 1. the main module can be used as entrypoint for the functions so, for example:
from wasmer import function
This may be achieved by changing the current definition from:
/// src/lib.rs
#[pymodule]
fn wasmer(_py: Python, module: &PyModule) -> PyResult<()> { ... }
to using #[pymodinit]
as here so to take advantage of add_function
and the new pyo3::wrap_pyfunction
and pyo3::wrap_pymodule
[ADDITION]
-
- (abstract away loading binary) Autodiscover functionality for binary. User should not be asked to explicitly point and load the
.wasm
file; on the contrarypython-ext-wasmer
should look and find the file in project's sub-directories or in a dedicated directory.
- (abstract away loading binary) Autodiscover functionality for binary. User should not be asked to explicitly point and load the
P.S. For now the format of the list can be:
- (objective) Implementation
Ideally should be the exported functions, but this leads a problem with exported
memory
. Two options here: export it with the exported functions ONLY if there's no other exportedmemory()
function, or left it as an advanced use case that would require direct access to Wasmer API (I think there should no be problems since it's the same memory region, no matter how do you access or reference to it...).