la10736
Can #[files] use relative paths
I have a project I contribute to that uses Nix to build a Rust project that uses the #[files(...)] feature of rstest. But because I am on macOS which compiles and runs the tests in different directories and because #[files(...)] encodes absolute paths the tests fail on my machine.
Would it be possible to use a relative path?
Right now I am more or less the only one using macOS and I can get around it for now by using cargo for local development but if we ever setup CI for macOS this will also break there.
There is something weird in what you're writing. Retest uses paths relative to Project's manifest file (and then makes them absolute) and normally that's also the folder where the tests run.
What we really cannot know is where exactly the user runs tests: that's why retest uses the absolute path.
Anyway I cannot understand where your tests fail: a compile time or at runtime?
Can you share the error message?
Il ven 16 ago 2024, 00:34 Brian Olsen @.***> ha scritto:
I have a project I contribute to that uses Nix to build a Rust project that uses the #[files(...)] feature of rstest. But because I am on macOS which compiles and runs the tests in different directories and because #[files(...)] encodes absolute paths the tests fail on my machine.
Would it be possible to use a relative path?
Right now I am more or less the only one using macOS and I can get around it for now by using cargo for local development but if we ever setup CI for macOS this will also break there.
— Reply to this email directly, view it on GitHub https://github.com/la10736/rstest/issues/271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5Y34KACU3VKVKWEKMBTVLZRUUIFAVCNFSM6AAAAABMTALJQWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3DSMJQGEZDCMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
It fails with unable to read JSON: Os { code: 2, kind: NotFound, message: "No such file or directory" } when I run the tests because it was built in a temporary directory that no longer exists when I run the tests (I don't control that it does this).
On linux this is not a problem because Nix uses mount namespaces to give the temporary directory where it builds tests the same absolute path as the temporary directory where it runs the tests and so the absolute paths of the test resources match.
I thought tests were always run in the directory where the manifest is. Could another way be that you can set an environment variable that is read at runtime to locate the test resource base directory?
Tests can be run everywhere: the simplest example is in a workspace where you cannot guest where the user invoke the test execution. Anyway tests are runnable in the target folder and we cannot never guess where the glob path is resolved on compile time.
What I can do is to introduce a environment variable like RSTEST_ROOT_PACKAGE evaluated when the tests are compiled and used to replace the cargo manifest path after that the glob pattern are resolved to find the test resources: I guess that can workaround to your issue.
The sad news is that I don't know when I can implement this feature, I can plan to do this while I'll implement #212 but I cannot say a date: sorry.
PR #277 should fit your needs: you can use #[base_dir = ${BASE_DIR:-}] that use the cargo root when BASE_DIR is not set and your provided one when is defined. I'll publish it ASAP