Stop setting duplicative CARGO_PKG env vars

[dzbarsky]

This support preexists the cargo_toml_env_vars, so we can just rely on that and avoid setting these vars from starlark, since they are both incomplete (missing some) and inconsistent (the VERSION ones defaulted to 0 in some cases, empty in others).

[UebelAndre]

Won't this be unset for normal rust_* targets?

[dzbarsky]

It will, but on the off chance that they actually need this they can either set env = {"CARGO_PKG_VERSION": version} explicitly or use cargo_toml_env_vars for proper support, like we do for cargo-bazel in this PR. I think it's confusing to have multiple ways to provide this functionality, and this one is more incomplete compared to cargo_toml_env_vars

See also https://bazelbuild.slack.com/archives/CSV56UT0F/p1759051609743919?thread_ts=1758229364.645099&cid=CSV56UT0F

[dzbarsky]

@UebelAndre another way of looking at it - previously, not setting the 'version' attribute on manually-written rust_library rules would mean they get compiled with CARGO_PKG_VERSION_MAJOR=0 and similar. That's also kinda weird and probably not the desired behavior...

[UebelAndre]

it's useful for things like clap which basically embeds the binary version for free in your crate due to these environment variables. While I can see the argument for separating out cargo environment variables I think the few that are there do offer some convenience folks have already taken advantage of. If this were to change I think it would need an incompatibility flag.

[krasimirgg]

+1 to keep the existing defaults CARGO_PKG_* derived from the rust_* rules in skylark. Many random crates in the ecosystem examine these and we have setup that imports them, generating BUILD files, deriving the crate name and version of the target from the Cargo.toml file in the process, and discarding the Cargo.toml files after that. While the defaults are not always correct, these defaults cover a good chunk of crates in our experience.

I agree it's super confusing in the presence of cargo_toml_env_vars, and there I think we shouldn't derive the defaults. Instead of a new incompatibility flag, could we make it that the implementation detects the presence of cargo_toml_env_vars dependency and disables the defaults derivation if that's present?

[dzbarsky]

cargo_toml_env_vars is just a .env file, could your import process write a .env file with the values instead? (That would be pretty similar to what I'm doing in rules_rs)

If we think changing this is too annoying I'm happy to stick it behind an incompatible flag, that would be good enough for my purposes

[krasimirgg]

I see, then adding an incompatible flag sounds good.

We could update the generators, but we can't update all crates' build files all at once (it's like like each crate is updated independently on its own schedule by separate groups of people). So we'll need the flexibility to opt in and out of this feature on a per-target basis if we are to move over.

A few more thoughts just to clarify my mental model:

• about the rust_library.version attribute: it is documented as an explicit way to stamp out the cargo env var. In the new mode, will this be a no-op?
• how does the cargo_toml_env_vars feature interact with rust_library.rustc_env when there are duplicate keys? Naively, rustc_env takes precedence right?

[dzbarsky]

How would you guys feel if we just stopped defaulting the version to 0.0.0 and left the vars unset in case the version wasn't provided? That would match the handling in the build_script rule and would give users an easy way to opt out of this behavior for all the version vars. It would also allow to share the duplicated parsing implementations that are inconsistent.

That would leave only CARGO_PKG_NAME which is sadly used by clap. (Fun fact, that usage is incorrect and it should use CARGO_BIN_NAME to get the right names, but that requires a clap fix...). We can tackle that one another day