Option to cargo run to make it set the project dir as the current working directory

[ilyagr]

Problem

I set up a cargo alias in .cargo/config.toml as follows:

[alias]
gen-cli-reference = "run -- generate-cli-reference docs/cli-reference.md"

The goal is so that cargo gen-cli-reference would be a nice cross-platform way a developer can auto-generate some docs.

This only works from the root directory of the project, because cargo run runs the binary in the current working directory.

Proposed Solution

I would like an option cargo run --in-project-dir that runs the binary from the root of the project, which is $CARGO_MANIFEST_DIR, I think. Then, I could define

[alias]
gen-cli-reference = "run --in-project-dir -- generate-cli-reference docs/cli-reference.md"

and cargo gen-cli-reference would work from anywhere.

Notes

Workaround: An alternative might be to write an xtask that reads $CARGO_MANIFEST_DIR (Update: I checked that this is indeed available to a program running with cargo run). The xtask would then execute cargo run.

I think this could work well, but would require quite a bit of boilerplate code.

[epage]

For myself, this feels like a fairly specialized flag for run. I wonder if another approach is to design this into a more advanced "alias" system that I would one day love to have. Unfortunately, that is less firmly defined and very low on most people's priority lists.

[weihanglo]

Another issue in this proposal is the semantics of --in-project-dir. Does it refer to the workspace root or thee package root directory? I believe both of them are reasonable choices, but you cannot satisfy both usages with only one boolean flag.

And agree with epage this is fairly specialized and a bit low in priority. xtask is indeed a good alternative, as you've mentioned. Cargo itself also makes use of it to determine package/workspace root. If you'd like to get the directory rustc is invoked from, see the unstable CARGO_RUSTC_CURRENT_DIR env var.

Some other issues might be related:

• Extend aliases: allow arbitrary commands #6575
• Support environment variable expansion in config.toml #10789
• Let aliases in .cargo/config.toml specify environment variables #12477

Since there is an alternative and nothing blocks people from using that, I'll label this as P-low as this moment. Please let us know if there is more info you'd like to add :)

[ilyagr]

I think this is fair, thanks for the example and the suggestions!

Another thing I missed is that run -- generate-cli-reference > docs/cli-reference.md couldn't be an alias. OTOH, I'm not sure whether that should be in-scope.

[weihanglo]

When you run cargo run -- generate-cli-reference > docs/cli-reference.md in your shell, > is parsed and interpreted as redirections by the shell. However, when it is an alias, there is no shell involved in parsing it in Cargo, so a list of args ["generate-cli-reference", ">", "docs/cli-reference.md"] will be passed to the running executable I believe. This is discussed in #6575.

[ilyagr]

Yes, it'd need a different syntax, or some other solution. I don't have a good solution for redirection in mind at the moment. Shelling out would defeat the purpose of portability to Windows.

[tisonkun]

I'm running into this and find a proper workaround:

[env]
CARGO_WORKSPACE_DIR = { value = "", relative = true }

[alias]
o = "run --manifest-path $CARGO_WORKSPACE_DIR/dev/Cargo.toml --"

However, it seems alias string doesn't resolve env var and thus this fails to work. But perhaps the direction is worth to dig more.

[weihanglo]

There is no variable substitution in [alias] yet. We'll need to define a proper cross-platform escape for that. See #13348 (comment) for relevant issues and discussions.