Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo wasi test should preopen the current dir by default #128

Open
ricochet opened this issue Dec 27, 2022 · 2 comments · May be fixed by #129
Open

cargo wasi test should preopen the current dir by default #128

ricochet opened this issue Dec 27, 2022 · 2 comments · May be fixed by #129

Comments

@ricochet
Copy link

Related to #17, tests that rely on any kind of test file, like expected results or test data, are unable to run with cargo wasi test.

When running tests, we should have a sensible default like --dir=.. We could use the same mechanism proposed in #19, but I would still want to provide a default preopen. This will make converting existing projects to Wasm and WASI as seamless as possible.

git clone https://github.com/image-rs/image-tiff.git
cd image-tiff
cargo build && cargo test # works

cargo wasi build && cargo wasi test # should also "just work"
@ricochet
Copy link
Author

A workaround is to run with:

CARGO_TARGET_WASM32_WASI_RUNNER="wasmtime --dir=." cargo wasi test

ricochet added a commit to ricochet/cargo-wasi that referenced this issue Dec 28, 2022
This PR defaults `cargo wasi test` to always be run
with the current working directory preopened.
The goal is to allow existing tests to run without modification.

Fixes bytecodealliance#128
@ricochet ricochet linked a pull request Dec 28, 2022 that will close this issue
ricochet added a commit to ricochet/cargo-wasi that referenced this issue Dec 29, 2022
This PR defaults `cargo wasi test` to always be run
with the current working directory preopened.
The goal is to allow existing tests to run without modification.

Fixes bytecodealliance#128
@TBBle
Copy link

TBBle commented May 30, 2024

I just hit this, and unless there's a better way to build filenames for test fixtures that I (a very new Rust learner) am unaware of, the solution probably needs to also ensure the CARGO_MANIFEST_DIR env-var is passed into wasmtime.

My currently-working env-var is (PowerShell)

$Env:CARGO_TARGET_WASM32_WASI_RUNNER="wasmtime --dir=${PWD} --env CARGO_MANIFEST_DIR=${PWD}

which makes the following work with just cargo test:

    let manfest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
    let fixture = path!(
        Path::new(&manfest_dir) / "tests" / "fixtures" / "2024-05-30" / "BlueprintList_info.json"
    );

    let data = fs::read_to_string(fixture).unwrap();

Without the --env CARGO_MANIFEST_DIR value, the call to env::var("CARGO_MANIFEST_DIR").unwrap(); panics with called ``Result::unwrap()`` on an ``Err`` value: NotPresent.

Edit: Playing around a bit,

$Env:CARGO_TARGET_WASM32_WASI_RUNNER="wasmtime --dir=${PWD}::/ --env CARGO_MANIFEST_DIR=/"

seems to work better, as it doesn't get confused by leading backslashes in CLI parameters using cargo wasi run, i.e., this works with the mapping to /, but fails with my earlier version with no guest mapping.

cargo wasi run .\tests\fixtures\2024-05-30\BlueprintList_info.json

This works in both cases, but tab-completion in PowerShell or CMD will convert it to the above.

cargo wasi run ./tests\fixtures\2024-05-30\BlueprintList_info.json

Might be a good time to clarify that I'm using Windows for this, in case that affects more than just the directory-seperator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants