Matrix-math example - no world named `matrix-math` in package

[k-mack]

Following the matrix-math example in fa666b9c16e3f46ae4f77372add5f59443fe65eb, I receive the following error:

componentize-py --wit-path src/componentize-py-fa666b9/wit --world matrix-math componentize app -o matrix-math.wasm
Traceback (most recent call last):
  File "/usr/local/bin/componentize-py", line 8, in <module>
    sys.exit(script())
AssertionError: no world named `matrix-math` in package

I attempted to fully qualify the world using its package name, but that didn't help:

componentize-py --wit-path src/componentize-py-fa666b9/wit --world "componentize-py:init/matrix-math" componentize app -o matrix-math.wasm
Traceback (most recent call last):
  File "/usr/local/bin/componentize-py", line 8, in <module>
    sys.exit(script())
AssertionError: unknown package `componentize-py:init`

I'm running the example inside a python:3.10.14-slim container.

[dicej]

Thanks for reporting this, @k-mack. I'm having trouble reproducing it, though. Here's what I did:

docker run --rm -it --entrypoint bash python:3.10.14-slim
pip install componentize-py
apt-get update
apt-get install -y git curl
git clone https://github.com/bytecodealliance/componentize-py
cd componentize-py/examples/matrix-math/
curl -OL https://github.com/dicej/wasi-wheels/releases/download/v0.0.1/numpy-wasi.tar.gz
tar xf numpy-wasi.tar.gz
componentize-py -d ../../wit -w matrix-math componentize app -o matrix-math.wasm

That worked for me. Would you mind sharing the exact commands you're using?

[k-mack]

Interesting. Your sequence of commands worked for me. There are a couple of differences in what I'm doing, but I'm not sure what's erroneous about it.

Here's the Dockerfile I use to create the image:

# Dockerfile.wasm-component
FROM python:3.10.14-slim

WORKDIR /workspace

# Deps
RUN apt-get update && apt-get install -y curl xz-utils zip && \
    curl -LO https://github.com/bytecodealliance/wasmtime/releases/download/v19.0.2/wasmtime-v19.0.2-x86_64-linux.tar.xz && \
    tar --xz -xf wasmtime-v19.0.2-x86_64-linux.tar.xz && mv wasmtime-v19.0.2-x86_64-linux wasmtime && \
    pip install componentize-py==0.13.3 && \
    curl -OL https://github.com/dicej/wasi-wheels/releases/download/v0.0.1/numpy-wasi.tar.gz && \
    tar -xf numpy-wasi.tar.gz

# Componentize-py src
RUN curl -LO https://github.com/bytecodealliance/componentize-py/archive/fa666b9c16e3f46ae4f77372add5f59443fe65eb.zip && \
    unzip -d src fa666b9c16e3f46ae4f77372add5f59443fe65eb.zip && \
    mv src/componentize-py-fa666b9c16e3f46ae4f77372add5f59443fe65eb src/componentize-py-fa666b9 && \
    cp src/componentize-py-fa666b9/examples/matrix-math/app.py .

Build the image, run the container, and run componentize-py:

docker build -t componentize-py:test -f Dockerfile.wasm-component .
docker run --rm -it componentize-py:test /bin/bash
componentize-py --wit-path src/componentize-py-fa666b9/wit --world matrix-math componentize app -o matrix-math.wasm

The matrix-math world is in the wit path:

cat src/componentize-py-fa666b9/wit/matrix-math.wit 
world matrix-math {
  include wasi:cli/command@0.2.0;

  export multiply: func(a: list<list<float64>>, b: list<list<float64>>) -> result<list<list<float64>>, string>;
}

[dicej]

Okay, I figured it out. The problem is due to a combination of factors:

• componentize-py uses the current working directory as the Python path (i.e. the directory under which to search for the application code and any of its dependencies)
• When generating a component, it searches the Python path (and all its subdirectories) for componentize-py.toml files, and if it finds any it uses them to locate WIT files
• The componentize-py source code contains a couple of componentize-py.toml files for testing, so when you unzip the source tree into a subdirectory of the current directory, it finds those files and tries to use them

You can avoid the above by removing the directory containing the test componentize-py.toml files, e.g. rm -r src/componentize-py-fa666b9/src/test prior to running the componentize subcommand.

There's currently a lot of implicit behavior in the componentize-py CLI, leading to subtle issues like this. The motivation is to make it "do what you mean" most of the time, but sometimes it backfires. I'm open to suggestions about how to improve it and make it less surprising, while still making it do the right thing with minimal input.

[k-mack]

Thanks, @dicej! I'll have to play around with componentize-py.toml files to get a better feel for the tool, and I'll contribute back any suggestions I may have along the way. I was able to componentize some Python code, transpile it with jco, and run it in the browser, which feels pretty good. Thanks again for your quick help.