Can't inherit a CARGO_PKG_README which was missing from the workspace

[Sh4d1]

Hello!

I'm running into this error when upgrading to rules rust 0.61 (from 0.57):

Can't inherit a CARGO_PKG_README which was missing from the workspace

Digged a bit, and this patch makes the build work:

diff --git cargo/cargo_toml_variable_extractor/main.rs cargo/cargo_toml_variable_extractor/main.rs
index 8e67307e..4562c66d 100644
--- cargo/cargo_toml_variable_extractor/main.rs
+++ cargo/cargo_toml_variable_extractor/main.rs
@@ -233,9 +233,7 @@ fn print_inheritable_path(
                 .join(std::path::MAIN_SEPARATOR_STR);
             Some(joined)
         }
-        (Some(InheritableString::Inherit(_)), None) => {
-            panic!("Can't inherit a {key} which was missing from the workspace")
-        }
+        (Some(InheritableString::Inherit(_)), None) => None,
         _ => None,
     };
     print_optional_env_str(out, key, maybe_path.as_deref());

However not sure it's what is wanted (did not really dig into the whole inheritance thing). I can open a PR as is if that what we want, but I guess it'll break some other config?

[illicitonion]

Which crate are you building? This codepath shouldn't be getting hit on third-party crates (because crates.io flattens workspace manifests), so this should only be happening if you're explicitly using the cargo_toml_env_vars rule yourself...

[Sh4d1]

So I'm not using cargo_toml_env_vars at all, but I tried the upgrade again and it worked (I was trying it during a switch to rust 2024, and now tried after the switch). Can't seem to reproduce for now, I'll close, thanks!

[stormshield-fabs]

I encountered the same issue while using a [patch] section.

The following Cargo.toml

[package]
name = "eyre-bazel-demo"
version = "0.1.0"
edition = "2024"

[dependencies]
eyre = "1"

[patch.crates-io]
eyre = { git = "https://github.com/eyre-rs/eyre.git", branch = "master" }

used with from_cargo yields this error

Can't inherit a CARGO_PKG_README which was missing from the workspace

[Sh4d1]

I was going to reopen it with the same comment 😅 unpinned my eyre/color-eyere deps and the errors disappeared!

[alexkirsz]

This also happens for us when using a crate.spec pointing to a git repo (similar to @stormshield-fabs's issue).

[brunal]

I'm also hitting this bug when I want to depend on e.g. apache/datafusion directly from git.

It panics when trying to build the sub-project datafusion-catalog or datafusion-catalog-listing.

[sfc-gh-bhannel]

I am also encountering this with crate.spec pointing to a git repo. I would love to have a workaround.

[sfc-gh-bhannel]

Pinning my rules_rust version to 0.58.0, before https://github.com/bazelbuild/rules_rust/commit/0b5e15bc296a83e55370ac77963e2bf8b0414ce6, resolves this issue.

cc @illicitonion

[brunal]

The cargo_toml_env_vars() BUILD target preparation happens at:

https://github.com/bazelbuild/rules_rust/blob/f04b2a6f9dc3f26e29563867155da8577b7203ad/crate_universe/src/rendering.rs#L467-L470

This does not feature the workspace Cargo.toml, despite it being supported:

https://github.com/bazelbuild/rules_rust/blob/f04b2a6f9dc3f26e29563867155da8577b7203ad/cargo/private/cargo_toml_env_vars.bzl#L27-L39

The current CrateContext (at https://github.com/bazelbuild/rules_rust/blob/f04b2a6f9dc3f26e29563867155da8577b7203ad/crate_universe/src/context/crate_context.rs#L294) does not seem to know about the workspace Cargo.toml. I wonder if we can know about it with its inputs:

https://github.com/bazelbuild/rules_rust/blob/f04b2a6f9dc3f26e29563867155da8577b7203ad/crate_universe/src/context/crate_context.rs#L1129-L1138

We might have to add a target for the workspace's Cargo.toml, and pipe that through -- but it is getting beyond my current expertise.

In the meantime, I think cargo_toml_variable_extractor should be able to emit errors/warnings instead of crashing. As I understand it, the inheritence feature currently works with vendored BUILD.bazel, where you can set the workspace's Cargo.toml. I'll send a MR that emits errors instead of crashing + adds a flag to control whether to error out or just log.

[brunal]

@sfc-gh-bhannel a less radical solution is to patch out the readme line from the subcrate's Cargo.toml. A single patch file should work with ~any crate.

[illicitonion]

The issue here is that in crate_universe we assume that a crate is never in a workspace, because when things are published to crates.io workspaces are normalised into non-workspace Cargo.toml files.

This is why people are only seeing this for git dependencies within a Cargo workspace.

You can work around this by setting generate_cargo_toml_env_vars to False in a render_config (https://bazelbuild.github.io/rules_rust/crate_universe_bzlmod.html#crate.render_config-generate_cargo_toml_env_vars).

If someone wanted to fix this, they'd need to conditionally add a workspace attribute to https://github.com/bazelbuild/rules_rust/blob/f04b2a6f9dc3f26e29563867155da8577b7203ad/crate_universe/src/rendering.rs#L467-L470 - we'd need to pipe through enough information in the CrateContext to identify the label of the workspace Cargo.toml file so we can properly populate that attribute. I'd gladly review a PR which contributed this.

[illicitonion]

(Also, thanks to @brunal for the analysis above, it's spot on!)

[brunal]

I have a draft @ https://github.com/brunal/rules_rust/tree/no-workspace-readme. This pulls the workspace_prefix from WorkspaceMetadata. However, trying it out, it seems that WorkspaceMetadata::workspace_prefix is unset.

@illicitonion , do you have tips for debugging this kind of things? I'm trying it out by pulling the forked rules_rust on my repo but it seems that changing crate_universe/src/... rust files does not cause my repo to pull the changed versions, so I can't properly iterate on it...