glob! panic

[akesson]

Love using insta! Thanks for doing it!

It's my 3rd day doing Rust, so maybe it's just me doing something wrong (sorry in that case).

I was running glob tests in a simple project setup and everything worked as a charm, but then I re-organized the project into a workspace to host more binaries/libraries and it stopped working.

This is the test (in a simplified format, the original stuff in comments):

fn test_html_files() {
    println!("{:?}", env::current_dir());
    glob!("*", |path| { //glob!("tests/htmlfiles/*.html", |path| {
        println!("{:?}", path);
        // let html = Html::new(path).unwrap();
        // html.process(None).unwrap();
        // assert_snapshot!(html.root.to_string());
    });
}

But fails on the glob! line with:

---- test_html_files stdout ----
Ok("/Users/hakesson/Developer/Polyglot/rust-dataprocessing/pgproclib")
thread 'test_html_files' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', pgproclib/tests/tests.rs:10:5

When checking the path:

➜ ls /Users/hakesson/Developer/Polyglot/rust-dataprocessing/pgproclib
Cargo.toml src        tests

Stacktrace

``` stack backtrace: 0: backtrace::backtrace::libunwind::trace at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: ::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/io/mod.rs:1426 6: std::io::impls::>::write_fmt at src/libstd/io/impls.rs:156 7: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 8: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 9: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 10: std::panicking::default_hook at src/libstd/panicking.rs:221 11: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 12: rust_begin_unwind at src/libstd/panicking.rs:378 13: core::panicking::panic_fmt at src/libcore/panicking.rs:85 14: core::option::expect_none_failed at src/libcore/option.rs:1211 15: core::result::Result::unwrap at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/result.rs:1003 16: tests::test_html_files at pgproclib/tests/tests.rs:10 17: tests::test_html_files::{{closure}} at pgproclib/tests/tests.rs:8 18: core::ops::function::FnOnce::call_once at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/function.rs:232 19: as core::ops::function::FnOnce>::call_once at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/liballoc/boxed.rs:1017 20: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:86 21: std::panicking::try at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/panicking.rs:281 22: std::panic::catch_unwind at /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/panic.rs:394 23: test::run_test_in_process at src/libtest/lib.rs:542 24: test::run_test::run_test_inner::{{closure}} at src/libtest/lib.rs:451 ```

Any ideas? It the full workspace setup info needed?

Do you happen to be running this test as a crate not in the root of the cargo workspace?

I just ran into what looks to be the same error, due to the fact that glob! computes the path as $CARGO_MANIFEST_DIR </> file!()

https://github.com/mitsuhiko/insta/blob/e9d6f1997ba289b6dd6dff7db0ce2ff9db57b697/src/macros.rs#L344-L349

The problem seems to be that file!() is relative to the workspace root manifest, and insta is assuming that it's relative to the $CARGO_MANIFEST_DIR manifest (which I would've assumed, too, before tracking down this panic).

So in my case I have

$CARGO_MANIFEST_DIR = "D:\\repos\\cad97\\pegcel\\crates\\codegen"
            file!() =                           "crates\\codegen\\tests\\snapshot.rs"

so instead of the glob having a base of the directory that the file is in, it has a base of effectively ../crates/codegen/tests.

I don't know if there's a way to do exactly what we want here without cargo adding e.g. $CARGO_WORKSPACE_DIR.

[CAD97]

It seems we already have a workaround commented on the issue for a workspace dir env var.

[nikhilm]

Would love to get this fixed. Right now I'm re-implementing the glob_exec function in my code so I can use insta within a workspace.

[CAD97]

If people don't mind using a git dependency in the meantime, you can use the fix in #123 directly:

insta = { git = "https://github.com/CAD97/insta.git", branch = "fix-119" }

@mitsuhiko, any estimate when we might be able to merge and publish that fix? Without it, it's completely impossible to use insta's glob support outside of the root-located crate in a workspace.