feat: Add CARGO_RUSTC_CURRENT_DIR (unstable)
#12996
Conversation
This will make it less likely that anything that depends on them will get moved before them and makes it easier to consistently add logic that depends on them.
This will make it easier to verify other env variables later
This is an alternative to rust-lang#12158's `CARGO_WORKSPACE_DIR` that was implementing the solution to rust-lang#3946 that previously discussed in the cargo team meeting. `CARGO_WORKSPACE_DIR` is a bit awkward to document / describe because its the effective workspace directory of the thing being built. If the thing being built doesn't have a workspace, it falls back to `CARGO_MANIFEST_DIR`. It would also be hard to take into account what the `CARGO_WORKSPACE_DIR` would be for path dependencies into foreign workspaces *and* it wouldn't solve the problem the user is having. What the user really wants is the CWD of rustc when it is invoked. This is much simpler to describe and is accurate when using a path dependency to a foreign package. Because the CWD is a much simpler mechanism to talk about, I figured we could diverge from our prior consensus and make it always present, rather than limiting it to tests. Remaining work for rust-lang#3946: get this stabilized
|
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
A-build-execution
epage
changed the title
CARGO_RUSTC_CURRENT_DIRCARGO_RUSTC_CURRENT_DIR (nightly-only)
epage
changed the title
CARGO_RUSTC_CURRENT_DIR (nightly-only)CARGO_RUSTC_CURRENT_DIR (unstable)
epage
force-pushed
the
current_dir
branch
2 times, most recently
from
f2669b5
to
5d0e5e4
Compare
There was a problem hiding this comment.
What the user really wants is the CWD of rustc when it is invoked.
This is much simpler to describe and is accurate when using a path
dependency to a foreign package.
I don't quite agree. People might just want to get the workspace root to do some tricks like generating code for other members. Granted this might seem like a "misuse" of build script but that is already a thing.
The proposed CARGO_RUSTC_CURRENT_DIR sounds harder to find and educate as well.
A previous iteration of the cargo team rejected that use case. When we met to discuss the problem, we intentionally designed the solution to exclude that use case, only allowing it for benches and tests. We also made it relative to communicate its wibbly wobbly nature.
Note that I'm not talking about documenting a fully generic
But really what we are trying to assist the user with is resolving |
epage
force-pushed
the
current_dir
branch
3 times, most recently
from
77c1b46
to
e81d84c
Compare
I figure we'd do an FCP on stabilization and can worry about the name then. I'd be curious to get this in a nightly for feedback from requesters. |
|
Thank you. All make sense as this is an nightly-only feature. @bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 7 commits in 71cd3a926f0cf41eeaf9f2a7f2194b2aff85b0f6..9b13310ca596020a737aaa47daa4ed9ff8898a2f 2023-11-20 15:30:57 +0000 to 2023-11-24 16:20:51 +0000 - feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable) (rust-lang/cargo#12996) - Exited with hard error when custom build file no existence or not in package (rust-lang/cargo#12995) - try running on windows (rust-lang/cargo#13042) - refactor(toml): Better abstract inheritance details (rust-lang/cargo#13021) - cargo-test-support: Add features to the default Cargo.toml file (rust-lang/cargo#12997) - Migrate rustfix to the cargo repo (rust-lang/cargo#13005) - typo: rusc -> rustc (rust-lang/cargo#13019) --- This also removes the check to ensure that `rustfix` between * src/tools/cargo * src/tools/compiletest has the same version, since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`. r? ghost
Update cargo 7 commits in 71cd3a926f0cf41eeaf9f2a7f2194b2aff85b0f6..9b13310ca596020a737aaa47daa4ed9ff8898a2f 2023-11-20 15:30:57 +0000 to 2023-11-24 16:20:51 +0000 - feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable) (rust-lang/cargo#12996) - Exited with hard error when custom build file no existence or not in package (rust-lang/cargo#12995) - try running on windows (rust-lang/cargo#13042) - refactor(toml): Better abstract inheritance details (rust-lang/cargo#13021) - cargo-test-support: Add features to the default Cargo.toml file (rust-lang/cargo#12997) - Migrate rustfix to the cargo repo (rust-lang/cargo#13005) - typo: rusc -> rustc (rust-lang/cargo#13019) --- This also removes the check to ensure that `rustfix` between * src/tools/cargo * src/tools/compiletest has the same version, since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`. r? ghost
This provides what cargo sets as the `current_dir` for the `rustc` process. While `std::file!` is unspecified in what it is relative to, it is relatively safe, it is generally relative to `rustc`s `current_dir`. This can be useful for snapshot testing. For example, `snapbox` has been using this macro on nightly since assert-rs/snapbox#247, falling back to finding a parent of `CARGO_MANIFEST_DIR`, if present. This has been in use in Cargo since rust-lang#13441. This was added in rust-lang#12996. Relevant points discussed in that issue: - This diverged from the original proposal from the Cargo team of having a `CARGO_WORKSPACE_DIR` that is the "workspace" of the package being built (ie registry packages would map to `CARGO_MANIFEST_DIR`). In looking at the `std::file!` use case, `CARGO_MANIFEST_DIR`, no matter how we defined it, would only sort of work because no sane definition of that maps to `rustc`'s `current_dir`.a This instead focuses on the mechanism currently being used. - Using "current dir" in the name is meant to be consistent with `std::env::current_dir`. - I can go either way on `CARGO_RUSTC` vs `RUSTC`. Existing related variables: - `RUSTC` - `RUSTC_WRAPPER` - `RUSTC_WORKSPACE_WRAPPER` - `RUSTFLAGS` (no `C`) - `CARGO_CACHE_RUSTC_INFO` Note that rust-lang#3946 was overly broad and covered many use cases. One of those was for packages to look up information on their dependents. Issue rust-lang#13484 is being left open to track that. Fixes rust-lang#3946
What does this PR try to resolve?
This is an alternative to #12158's
CARGO_WORKSPACE_DIRthat wasimplementing the solution to #3946 that previously discussed in the
cargo team meeting.
CARGO_WORKSPACE_DIRis a bit awkward to document / describe becauseits the effective workspace directory of the thing being built.
If the thing being built doesn't have a workspace, it falls back to
CARGO_MANIFEST_DIR.It would also be hard to take into account what the
CARGO_WORKSPACE_DIRwould be for path dependencies into foreignworkspaces and it wouldn't solve the problem the user is having.
What the user really wants is the CWD of rustc when it is invoked.
This is much simpler to describe and is accurate when using a path
dependency to a foreign package.
Because the CWD is a much simpler mechanism to talk about, I figured we
could diverge from our prior consensus and make it always present,
rather than limiting it to tests.
How should we test and review this PR?
The preparatory refactor commits have explanation for why they were to help
Additional information
Remaining work for #3946: get this stabilized