Working directory different between cargo run and test

[dkorsunsky]

I am not sure whether this should be classified as a bug...

When I use cargo run from my workspace root directory, my working directory seems to always point to the manifest dir for the top-level workspace. However, when I use cargo test from the same location, my working directory will be set to the manifest dir of the crate, whose tests are being run at the time.

This is really counter-intuitive behaviour, IMHO.

Should this not be consistent in all cases between cargo run and cargo test? Specifically, if I cargo run/test from the workspace root, it should set working directory to the workspace manifest dir. If I cargo run/test from the specific crate directory (or maybe even with the -p option), the working directory should be set to the manifest dir for that crate.

Incidentally, using the --manifest-path option doesn't seem to affect any of the above.

[ehuss]

Thanks for the report! This is intentional behavior, though I understand how it can be confusing. cargo run keeps the working directory of wherever you ran cargo from. This is equivalent to running the process directly. This allows processes that interact with files to behave just like you ran the process normally. Imagine if you were writing a replacement for the utility du, then you can go to some directory and run cargo run --manifest-path /path/to/Cargo.toml, and it will show the disk usage in the current directory.

The reason cargo test always runs from within the package root is to allow tests to reliably access files from within the package. For example, imagine a test has some static data files used to drive the test or for comparison, the test can simply open the relative path, and not need to worry too much about where it is running from.

I don't think either of these behaviors can be changed, but it seems like the documentation could be clarified.

[dkorsunsky]

Thank you for getting back to me. While it still seems baffling, given the context in which I imagine most tests will be run, I'll find ways of dealing with it (at the moment, using CARGO_MANIFEST_DIR as an "invariant" which always refers to the package root does the trick).

[jofas]

Hmm, maybe adding a subsection here along the lines of "Running tests in a workspace" would clarify the behaviour of cargo test in a workspace? Any thoughts?

[weihanglo]

Hmm, maybe adding a subsection here along the lines of "Running tests in a workspace" would clarify the behaviour of cargo test in a workspace? Any thoughts?

Can you verify if cargo test -p <some-dependency> has the same behavior, switching the working directory to that dependency? If in that case, maybe the subsection title should change to “Working directory of tests being run” or something better.

We can also add a similar subsection under cargo run manpage if there is no such thing. And could cross-reference each other if it doesn't make the whole paragraph too lengthy.

[jofas]

Can you verify if cargo test -p <some-dependency> has the same behavior, switching the working directory to that dependency?

cargo test -p <some-dependency> switches the directory to the root of the given workspace member. So yes, same behaviour.

We can also add a similar subsection under cargo run manpage if there is no such thing.

There isn't. I like the idea of linking the two sections. At first I thought that cargo run's behaviour doesn't need to be explained, but it is actually somewhat unintuitive that the command is not executed from the package's root directory, whereas cargo test is. So I changed my mind and think this design decision should be explained in the manpages of cargo run, too.

[weihanglo]

Also, if you find the piece of code determining that behavior, and it makes sense to add a comment there explaining it, add it please 😁

[jofas]

@rustbot claim