Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag that set working directory for cargo run #10974

Closed
KSXGitHub opened this issue Aug 11, 2022 · 4 comments
Closed

Add flag that set working directory for cargo run #10974

KSXGitHub opened this issue Aug 11, 2022 · 4 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@KSXGitHub
Copy link

Problem

Today I found myself needing to run cargo run in a directory separated from the Rust project. If I attempt cd $target_dir && cargo run, it would only emit an error for missing Cargo.toml. The only way to do it was to add $project/target/debug to $PATH but it would come with its own set of inconveniences.

Proposed Solution

Implement a flag named --work-dir <DIR> (or whatever name you may find more intuitive and conventional) to cargo run to let user set working directory for the binary before run.

Notes

No response

@KSXGitHub KSXGitHub added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Aug 11, 2022
@epage
Copy link
Contributor

epage commented Aug 11, 2022

Alternatively, you can do cargo run --manifest-path <toml path> though that can run into issues, see #2930. To work around that, we are considering #10952

Some quick thoughts:

  • resolving this feels like the workarounds are piling up.
  • we'd need to make the distinction between this and -C clear.

@ehuss
Copy link
Contributor

ehuss commented Aug 13, 2022

In addition to the above, cargo will run the executable from wherever cargo is run from. If it is outside of your project directory, you can pass --manifest-path to specify where the project is.

I'm going to close with the same reasoning from #9864 (comment), which lists several other workarounds.

@ehuss ehuss closed this as not planned Won't fix, can't repro, duplicate, stale Aug 13, 2022
@epage
Copy link
Contributor

epage commented Aug 14, 2022

@ehuss what are your thoughts on the limitation of --manifest-path while we don't have a path forward on #2930?

(personally, I've not needed config files and make heavy use of --manifest-path to run bins our of source)

@ehuss
Copy link
Contributor

ehuss commented Aug 14, 2022

If the user wants the equivalent of cargo build && cd /some/path && /path/to/project/target/debug/foo to pick up the config files, I think scripting that with something like xtask or the other suggestions in the linked issue is probably the best path forward now. Or using seperate terminals. Or building from an editor and launching in a terminal. There are quite a few different ways to deal with it.

As for the config file discovery issue itself, I think we should continue to scrutinize the use cases that require config files. If there are common tasks that are not environment-specific, those should likely be pushed to Cargo.toml or a build script. For example, one use case that some people wanted package-specific config files was to set the target which is now covered by per-package-target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

No branches or pull requests

3 participants