cargo add hangs on Adding to dependencies

[ghost]

Problem

If I run this command, it completes in about 2 seconds:

cargo add --no-default-features gitoxide

if I run this command, it never completes:

> cargo add gitoxide
    Updating crates.io index
      Adding gitoxide v0.23.0 to dependencies.

I tried waiting for 5 minutes.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

[weihanglo]

Thanks for the report, and interesting!

It turns out that gitoxide has two features enabling each other — prodash-render-line-crossterm will enable prodash-render-line and vice versa.

• https://github.com/Byron/gitoxide/blob/93e75fed454ed8b342231bde4638db90e407ce52/Cargo.toml#L40
• https://github.com/Byron/gitoxide/blob/93e75fed454ed8b342231bde4638db90e407ce52/Cargo.toml#L84

I feel like adding a filter here may fix this issue.

diff --git a/src/cargo/ops/cargo_add/mod.rs b/src/cargo/ops/cargo_add/mod.rs
index c22466399..5c519ac09 100644
--- a/src/cargo/ops/cargo_add/mod.rs
+++ b/src/cargo/ops/cargo_add/mod.rs
@@ -726,7 +726,8 @@ impl DependencyUI {
                     .get(next)
                     .into_iter()
                     .flatten()
-                    .map(|s| s.as_str()),
+                    .map(|s| s.as_str())
+                    .filter(|s| !activated.contains(s)),
             );
             activated.extend(
                 self.available_features

[ghost]

@weihanglo thanks for the response. Do you feel that this is also an error with GitOxide itself, or just an error with Cargo? I would like to also post an issue to GitOxide if they made a mistake

[weihanglo]

Not entirely sure but I think it's totally valid to have features depending on each other. When cargo building, the feature resolve should handle them well. That is, I see it as a bug in cargo add not in gitoxide.

BTW, it seems that you probably don't want to cargo add gitxodie, as it is a binary not a library crate.

[ghost]

BTW, it seems that you probably don't want to cargo add gitxodie, as it is a binary not a library crate.

Yes I think I agree, probably cargo add gix would be better. however I think current Cargo behavior of permanent loop is not ideal, loop should end. To address your concern, perhaps Cargo could warn the user when trying to add a binary crate, however I think that is low priority compared to the loop error.

[weihanglo]

To address your concern, perhaps Cargo could warn the user when trying to add a binary crate

Great idea! Would you mind opening an issue for that?

[jofas]

@rustbot claim

[epage]

Huh, never knew this was possible. Thanks for fixing for the report @4cq2 and the fix @jofas !