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

Duplicated alias rule in generated BUILD file #474

Open
jgao54 opened this issue Mar 16, 2022 · 3 comments
Open

Duplicated alias rule in generated BUILD file #474

jgao54 opened this issue Mar 16, 2022 · 3 comments

Comments

@jgao54
Copy link

jgao54 commented Mar 16, 2022

Hello, I have an existing project that uses cargo workspace and I am converting it to build with Bazel; and I am using cargo-raze (v0.15.0) in Remote mode.

There are two packages: A and B.
A's Cargo.toml contains:

[devDependencies]
clap = "3.0.14"

B's Cargo.toml contains:

[dependencies]
A = {path = "path/to/A" }
clap = "2.33.3" // or another crate that has a transitive dependency on clap 2.33.3

After running cargo raze, both versions are populated in the generated BUILD.bazel file with the same name:

alias(
    name = "clap",
    actual = "@raze__clap__2_33_3//:clap",
    tags = [
        "cargo-raze",
        "manual",
    ],
)

alias(
    name = "clap",
    actual = "@raze__clap__3_0_14//:clap",
    tags = [
        "cargo-raze",
        "manual",
    ],
)

Because of this, the project failed to build with:

Error in alias: alias rule 'clap' in package A conflicts with existing alias rule, defined at /path/to/A/cargo/BUILD.bazel:141:6

Temporary workaround is to manually edit the BUILD.bazel file and remove one of the aliases.

I also tried to rename clap in A's cargo.toml (i.e. clap3 = {package = "clap", version = "3.0.14"}), however it did not affect the generated BUILD.bazel file.

(I saw #282 and #425, and thought this was fixed, but not familiar enough with cargo-raze to deduce why it didn't propagate the renaming)

@jgao54
Copy link
Author

jgao54 commented Mar 17, 2022

I took a look at the source code; it looks like the generated BUILD file by default iterates thru the package names from the flat list of packages in cargo metadata, and use "resolve" graph to determine crate renaming where applicable via the produce_workspace_aliases function.

However, since package A here is a workspace member and not a binary, it get skipped here, and the renaming context from resolve graph is lost -- so the final generated BUILD file contains the original package name.

@jgao54
Copy link
Author

jgao54 commented Mar 17, 2022

Here's a re-pro of the scenario described where the renaming is not honored in the generated aliases: https://github.com/jgao54/cargo-raze-example

@fmorency
Copy link

I also see this issue.

MRE: https://github.com/fmorency/bazelalias

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants