Panic: Cannot create absolute path from string

[UebelAndre]

Whenever I try to run my test in a debugger, I get the following error

running 1 test
thread 'metadata::tests::test_fetching_src' panicked at 'Cannot create absolute path from string '/var/folders/hf/phjl9q7501gb5wt_qr4ltn3m0000gn/T/.tmpIrQDOX/fake-crate.tar.gz': "environment variable not found"', /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/api/mock.rs:1115:63
stack backtrace:
   0: rust_begin_unwind
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
   1: core::panicking::panic_fmt
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
   2: core::option::expect_none_failed
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
   3: core::result::Result<T,E>::expect
             at /Users/user/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/result.rs:933
   4: httpmock::api::mock::Mock::return_body_from_file
             at /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/api/mock.rs:1115
   5: httpmock::Responders::body_from_file
             at /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/lib.rs:1185
   6: cargo_raze::metadata::tests::test_fetching_src::{{closure}}
             at ./src/metadata.rs:389
   7: httpmock::MockServer::mock_async::{{closure}}
             at /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/lib.rs:481
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /Users/user/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/future/mod.rs:79
   9: <F as httpmock::util::Join>::join
             at /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/util.rs:71
  10: httpmock::MockServer::mock
             at /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/httpmock-0.5.0-beta.1/src/lib.rs:456
  11: cargo_raze::metadata::tests::test_fetching_src
             at ./src/metadata.rs:385
  12: cargo_raze::metadata::tests::test_fetching_src::{{closure}}
             at ./src/metadata.rs:342
  13: core::ops::function::FnOnce::call_once
             at /Users/user/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
  14: core::ops::function::FnOnce::call_once
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Repro

I created an example workspace that outlines this issue. repro.zip

I'm using Vscode and by simply clicking the debug button that appears over tests from the rust-analyzer plugin, I hit this panic.

I'm using 0.5.0-beta.1.

[alexliesenfeld]

Thanks for the report! I will look into it tonight.

[UebelAndre]

Sad to see this didn't make 0.5.0 but very hopeful for 0.5.1!! 😄

I think this project is pretty great so thanks for all the hard work so far!

[alexliesenfeld]

This issue is still on my radar and I planned a bugfix for the next release.

This issue comes up because the environment variable CARGO_MANIFEST_DIR is not set when running tests with a debugger (tested with both, VS Code and IntelliJ). Running the tests without a debugger attached works as expected. For this reason, I have categorized this as a minor issue and decided to release 0.5.0 to start getting feedback from the community.

I am working on a fix, though.

@UebelAndre Thanks for your workspace, it helped to reproduce this issue.

As a workaround, you can set the environment variable CARGO_MANIFEST_DIR manually to contain a path to the root of your project.

[UebelAndre]

Hey, just pining this issue. Any updates? 🙏 😅

[alexliesenfeld]

I have been busy lately, so no new updates on this for now. Is this a blocker for you?

[UebelAndre]

It's a blocker but has become a point of frustration for some folks. Is there no sane fallback that can be used to avoid this?

[UebelAndre]

I made another pull request to address this issue for my use cases. #24 Do you think it'd be something that could be included in 0.5.2? (not trying to keep you up late 😅 🙏 )

[alexliesenfeld]

Thanks for your PR again. I have changed your implementation slightly, but it's merged now into #22 .

[UebelAndre]

Thanks! Want me to close this issue? Users will still run into a similar panic for relative paths (i think)

[alexliesenfeld]

this should be fixed with #22 (v0.5.2)