cargo install doesn't set env variable defined in .cargo/config.toml

[cakebaker]

Problem

Hi,

In our project, coreutils, we have the following section in .cargo/config.toml:

[env]
PROJECT_NAME_FOR_VERSION_STRING = "uutils coreutils"

We then use the env! macro from std to retrieve the value. The macro emits a compilation error if the environment variable is not defined.

Everything works fine if I use cargo install with --path:

$ cargo install --path ~/projects/coreutils/ --locked

However, if I try to install it from crates.io with:

$ cargo install coreutils --locked

I get many errors about the environment variable not being defined at compile time, for example:

error: environment variable `PROJECT_NAME_FOR_VERSION_STRING` not defined at compile time
   --> /home/dho/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/uu_wc-0.1.0/src/wc.rs:399:18
    |
399 |         .version(uucore::crate_version!())

My initial thought was that .cargo/config.toml is missing from the crates file, but that's not the case as you can see when downloading the crates file from https://crates.io/api/v1/crates/coreutils/0.1.0/download.

Steps

I guess the steps are:

• add [env] section to .cargo/config.toml and define an env variable
• read the env variable with env! macro in the application
• publish crate
• cargo install <crate_name> --locked

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.87.0 (99624be96 2025-05-06)
release: 1.87.0
commit-hash: 99624be96e9d213b0e9b1e36451271f24e4a41d8
commit-date: 2025-05-06
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.4.1)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Arch Linux [64-bit]

[epage]

Yes, this is a surprising aspect to cargo install and config.toml in general.

config.toml is environmental configuration for where the command is being run, not where the command comes from. We actually make a small exception for cargo install to only be dependent on the user config and not also the current working directory so where you run it on your system isn't impacted as much,

As this looks like this is the same case as #14001, I'm going to close in favor of that issue. If there is a reason to keep this open, let us know!