initial duplicate bevy version lint

[DaAlbrecht]

A first draft of a quick lint to check if multiple versions of bevy are defined. #15

todos:

• create ui test
• better error message, perhaps use cargo metadata to get information about the crate versions.
• fix the span ( this should point to the crate causing the issue in the Cargo.toml)

error: Multiple versions of `bevy` found
  --> /Users/didi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy-0.13.2/src/lib.rs:1:1
   |
1  | / #![allow(clippy::single_component_path_imports)]
2  | |
3  | | //! [![](https://bevyengine.org/assets/bevy_logo_d...
4  | | //!
...  |
51 | | #[allow(unused_imports)]
52 | | use bevy_dylib;
   | |_______________^
   |
   = note: `#[deny(bevy::duplicate_bevy_dependencies)]` on by default

[BD103]

So far this looks good! I am interested in getting a span to Cargo.toml / Cargo.lock, though I'm unsure if the compiler will know that file exists. Ping me when this is ready for a final review!

[DaAlbrecht]

example of the lint message

error: Mismatching versions of `bevy` found
  --> Cargo.toml:10:26
   |
10 | leafwing-input-manager = "0.13"
   |                          ^^^^^^
   |
help: Expected all crates to use `bevy` 0.14.2
  --> Cargo.toml:8:8
   |
8  | bevy = { version = "0.14.2", features = ["android_shared_stdcxx"] }
   |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[BD103]

One function you may find useful is was_invoked_from_cargo(), which detects whether we're being run from Cargo or not. We can use this to skip Cargo lints when bevy_lint_driver is called directly!

[DaAlbrecht]

One function you may find useful is was_invoked_from_cargo(), which detects whether we're being run from Cargo or not. We can use this to skip Cargo lints when bevy_lint_driver is called directly!

nice catch! Thanks will add this.

[TimJentzsch]

@DaAlbrecht The tests are failing, because Bevy needs additional system packages to be installed on Linux.

I had the same issue in #222, so we can either merge that PR first and then merge main back in your branch or you can copy the CI-related changes here to fix this :)

[TimJentzsch]

In the CLI we are using the toml_edit crate to parse Cargo.toml, do you think we can use one or the other in both, to avoid duplication?

[TimJentzsch]

In the main CLI, we are using the cargo metadata command for a more robust method of finding the path to Cargo.toml.

Not sure how easy it would be to use that logic in the linter, I'd be fine to pull that out into a follow-up issue.
But essentially it would make the linter more robust to the location where it's called.

[TimJentzsch]

Oh, we retrieved and parsed this manually in the main CLI. We should probably use the crate there as well :D

[TimJentzsch]

Hmmm, I'm not sure if this is the right approach here, as the version string in Cargo.toml really is a VersionReq instead of a Version.

In the cargo metadata output is a resolve object, which I believe essentially contains the dependency graph.
Do you think we could search that for bevy entries and then extract the versions from the package ID? Then we already know it's two different versions and don't need to compare them.

I guess it would make it a bit harder though to find where the duplicated bevy version is coming from (and which of both the "main" Bevy version is).

[TimJentzsch]

Actually, I think you are already doing something similar?
I'm not sure if I'm understanding the code correctly

[TimJentzsch]

Super cool to have the spans here!

Bonus would be if it told you which Bevy version the dependency used instead, but that'd just be the cherry on top, feel free to leave it out