Stream: git-wasmtime

Topic: wasmtime / issue #10936 Wasmtime 32.0.0 can run CPython.w...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 20:29):

dragonulq opened issue #10936:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

The full code along with CPython.wasm and all its dependencies is available at this repo: https://github.com/dragonulq/github-rust-issue . I made a repository because CPython.wasm was too large to upload here and it is also easier to reproduce with all the files already there.

CPython.wasm can be run from the CLI, inside the directory with the ./python.sh script. You need to have the $WASMTIME_HOME variable set. This setup is without errors.

My Rust app has the usual boilerplate code to compile and instantiate a module. It can run other WASM modules but not CPython, which makes me think it has something to do with how I am setting up the environment for CPython, as it needs to enter other directories in order to run, like Lib. These are the relevant lines that do the setup:

`wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
wasi_ctx_builder.env("PYTHONHOME", "/build");

let wasi_ctx = (&mut wasi_ctx_builder)
    .inherit_stdio()
    .args(&argv)
    .build_p1();

`

Steps to Reproduce

To reproduce:

  1. git clone https://github.com/dragonulq/github-rust-issue.git .
  2. cd inside it.
  3. Run cargo run ./wasm32-wasip1/python.wasm.

Expected Results

I would expect to see the normal ">>>" prompt that python gives. This happens when run with CLI Wasmtime from the python.sh script.

Actual Results

Actual result is `Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
Exception ignored in the internal traceback machinery:
ModuleNotFoundError: No module named 'traceback'
ModuleNotFoundError: No module named 'encodings'

Current thread 0x012f860c (most recent call first):
<no Python frame>
`

Versions and Environment

Wasmtime version or commit: 32.0.0

Operating system: macOS Sequoia 15.5

Architecture: ARM64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 20:29):

dragonulq added the bug label to Issue #10936.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 20:30):

dragonulq edited issue #10936:

Test Case

The full code along with CPython.wasm and all its dependencies is available at this repo: https://github.com/dragonulq/github-rust-issue . I made a repository because CPython.wasm was too large to upload here and it is also easier to reproduce with all the files already there.

CPython.wasm can be run from the CLI, inside the directory with the ./python.sh script. You need to have the $WASMTIME_HOME variable set. This setup is without errors.

My Rust app has the usual boilerplate code to compile and instantiate a module. It can run other WASM modules but not CPython, which makes me think it has something to do with how I am setting up the environment for CPython, as it needs to enter other directories in order to run, like Lib. These are the relevant lines that do the setup:

`wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
wasi_ctx_builder.env("PYTHONHOME", "/build");

let wasi_ctx = (&mut wasi_ctx_builder)
    .inherit_stdio()
    .args(&argv)
    .build_p1();

`

Steps to Reproduce

To reproduce:

  1. git clone https://github.com/dragonulq/github-rust-issue.git .
  2. cd inside it.
  3. Run cargo run ./wasm32-wasip1/python.wasm.

Expected Results

I would expect to see the normal ">>>" prompt that python gives. This happens when run with CLI Wasmtime from the python.sh script.

Actual Results

Actual result is `Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
Exception ignored in the internal traceback machinery:
ModuleNotFoundError: No module named 'traceback'
ModuleNotFoundError: No module named 'encodings'

Current thread 0x012f860c (most recent call first):
<no Python frame>
`

Versions and Environment

Wasmtime version or commit: 32.0.0

Operating system: macOS Sequoia 15.5

Architecture: ARM64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 20:32):

dragonulq edited issue #10936:

Test Case

The full code along with CPython.wasm and all its dependencies is available at this repo: https://github.com/dragonulq/github-rust-issue . I made a repository because CPython.wasm was too large to upload here and it is also easier to reproduce with all the files already there.

CPython.wasm can be run from the CLI, inside the directory with the ./python.sh script. You need to have the $WASMTIME_HOME variable set. This setup is without errors.

My Rust app has the usual boilerplate code to compile and instantiate a module. It can run other WASM modules but not CPython, which makes me think it has something to do with how I am setting up the environment for CPython, as it needs to enter other directories in order to run, like Lib. These are the relevant lines that do the setup:

`wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
wasi_ctx_builder.env("PYTHONHOME", "/build");

let wasi_ctx = (&mut wasi_ctx_builder)
    .inherit_stdio()
    .args(&argv)
    .build_p1();`

Steps to Reproduce

To reproduce:

  1. git clone https://github.com/dragonulq/github-rust-issue.git .
  2. cd inside it.
  3. Run cargo run ./wasm32-wasip1/python.wasm.

Expected Results

I would expect to see the normal ">>>" prompt that python gives. This happens when run with CLI Wasmtime from the python.sh script.

Actual Results

Actual result is `Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
Exception ignored in the internal traceback machinery:
ModuleNotFoundError: No module named 'traceback'
ModuleNotFoundError: No module named 'encodings'

Current thread 0x012f860c (most recent call first):
<no Python frame>
`

Versions and Environment

Wasmtime version or commit: 32.0.0

Operating system: macOS Sequoia 15.5

Architecture: ARM64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 22:57):

dragonulq edited issue #10936:

Test Case

The full code along with CPython.wasm and all its dependencies is available at this repo: https://github.com/dragonulq/github-rust-issue . I made a repository because CPython.wasm was too large to upload here and it is also easier to reproduce with all the files already there.

CPython.wasm can be run from the CLI, inside the directory with the ./python.sh script. You need to have the $WASMTIME_HOME variable set. This setup is without errors.

My Rust app has the usual boilerplate code to compile and instantiate a module. It can run other WASM modules but not CPython. I am pretty sure the way I am setting the environment ( as it needs to enter other directories in order to run, like Lib) for CPython is correct, so this makes me think the only cause for not being able to run is a problem with Wasmtime. These are the relevant lines that do the setup:

`wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
wasi_ctx_builder.env("PYTHONHOME", "/build");

let wasi_ctx = (&mut wasi_ctx_builder)
    .inherit_stdio()
    .args(&argv)
    .build_p1();`

Steps to Reproduce

To reproduce:

  1. git clone https://github.com/dragonulq/github-rust-issue.git .
  2. cd inside it.
  3. Run cargo run ./wasm32-wasip1/python.wasm.

Expected Results

I would expect to see the normal ">>>" prompt that python gives. This happens when run with CLI Wasmtime from the python.sh script.

Actual Results

Actual result is `Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
Exception ignored in the internal traceback machinery:
ModuleNotFoundError: No module named 'traceback'
ModuleNotFoundError: No module named 'encodings'

Current thread 0x012f860c (most recent call first):
<no Python frame>
`

Versions and Environment

Wasmtime version or commit: 32.0.0

Operating system: macOS Sequoia 15.5

Architecture: ARM64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 05 2025 at 23:50):

pchickey commented on issue #10936:

I'm not an expert in Python but it looks to me like its internal search for modules is failing, which I expect comes down to some combination of the filesystem and environment variables available to it. I'm quite skeptical the problem is in wasmtime because the wasmtime-cli really does not do anything special, and I've never seen a bug that happened in a custom embedding and not the cli that turned out to be in wasmtime itself.

Before investigating this as a Wasmtime issue I'd suggest doing more work to verify that the filesystem and preopens in your own wasmtime embedding are precisely what works under wasmtime-cli, for example you could instrument your own build of wasmtime-cli to debug print exactly what gets passed to WasiCtxBuilder::preopened_dir and env, as well as in your own.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2025 at 15:54):

posborne commented on issue #10936:

@dragonulq As @pchickey suggests, you env vars aren't quite right. I tweaked things a bit and this works, though you'll want to probably dig into things further to sort out what bits should be derived from PYTHONHOME, etc.

diff --git a/wasm_launcher_issue.rs b/wasm_launcher_issue.rs
index 4171eff..0f9b64d 100644
--- a/wasm_launcher_issue.rs
+++ b/wasm_launcher_issue.rs
@@ -72,8 +72,8 @@ fn main() -> Result<()> {
     let host_path = cwd.join("wasm32-wasip1");

     wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
-    wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
-    wasi_ctx_builder.env("PYTHONHOME", "/build");
+    wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15:/Lib");
+    wasi_ctx_builder.env("PYTHONHOME", "/");

     let wasi_ctx = (&mut wasi_ctx_builder)
         .inherit_stdio()

Which gets me to this point:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.44s
     Running `target/debug/wasm-launcher ./wasm32-wasip1/python.wasm`
Python 3.15.0a0 (heads/main-dirty:8865b4f95b3, May 30 2025, 18:37:29) [Clang 20.1.1-wasi-sdk (https://github.com/llvm/llvm-project 424c2d9b7e4de40d080 on wasi
Type "help", "copyright", "credits" or "license" for more information.
warning: can't use pyrepl: No module named '_ctypes'
>>>

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2025 at 17:11):

pchickey closed issue #10936:

Test Case

The full code along with CPython.wasm and all its dependencies is available at this repo: https://github.com/dragonulq/github-rust-issue . I made a repository because CPython.wasm was too large to upload here and it is also easier to reproduce with all the files already there.

CPython.wasm can be run from the CLI, inside the directory with the ./python.sh script. You need to have the $WASMTIME_HOME variable set. This setup is without errors.

My Rust app has the usual boilerplate code to compile and instantiate a module. It can run other WASM modules but not CPython. I am pretty sure the way I am setting the environment ( as it needs to enter other directories in order to run, like Lib) for CPython is correct, so this makes me think the only cause for not being able to run is a problem with Wasmtime. These are the relevant lines that do the setup:

`wasi_ctx_builder.preopened_dir(host_path, "/", DirPerms::all(), FilePerms::all())?;
wasi_ctx_builder.env("PYTHONPATH", "/build/lib.wasi-wasm32-3.15");
wasi_ctx_builder.env("PYTHONHOME", "/build");

let wasi_ctx = (&mut wasi_ctx_builder)
    .inherit_stdio()
    .args(&argv)
    .build_p1();`

Steps to Reproduce

To reproduce:

  1. git clone https://github.com/dragonulq/github-rust-issue.git .
  2. cd inside it.
  3. Run cargo run ./wasm32-wasip1/python.wasm.

Expected Results

I would expect to see the normal ">>>" prompt that python gives. This happens when run with CLI Wasmtime from the python.sh script.

Actual Results

Actual result is `Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
Exception ignored in the internal traceback machinery:
ModuleNotFoundError: No module named 'traceback'
ModuleNotFoundError: No module named 'encodings'

Current thread 0x012f860c (most recent call first):
<no Python frame>
`

Versions and Environment

Wasmtime version or commit: 32.0.0

Operating system: macOS Sequoia 15.5

Architecture: ARM64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2025 at 17:11):

pchickey commented on issue #10936:

Thanks Paul!

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2025 at 18:24):

dragonulq commented on issue #10936:

Thank you! I wouldn't have thought of that.

Last updated: Dec 06 2025 at 06:05 UTC