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

cargo metadata lints #967

Open
oli-obk opened this issue May 30, 2016 · 4 comments
Open

cargo metadata lints #967

oli-obk opened this issue May 30, 2016 · 4 comments
Labels
T-cargo Type: cargo related

Comments

@oli-obk
Copy link
Contributor

oli-obk commented May 30, 2016

Should we add lints that check the cargo metadata for issues like having the same library, but different versions of it, in the dependency tree?

Or should that be in another project?

There are multiple granularities of such a lint.

  1. lint any time a crate appears with different versions (easy)
  2. lint only if the crate is included by the top level crate (easy)
  3. lint only if the multiple versions are observable at the top level crate (hard)

related:

rust-lang/cargo#2363
rust-lang/cargo#2064

@Manishearth
Copy link
Member

Sounds like another project, but not sure. We already lint this in Servo's tidy script, btw.

@oli-obk
Copy link
Contributor Author

oli-obk commented May 31, 2016

This is covered by cargo tree -d

Output for image 0.8:

byteorder v0.4.2
└── image v0.8.0 (file:///home/ws/ca8159/Projects/rust/image)

byteorder v0.5.1
└── jpeg-decoder v0.1.3
    └── image v0.8.0 (file:///home/ws/ca8159/Projects/rust/image)

still... it would probably be convenient to run such an analysis really early, like during plugin initialization, because every extra command one has to run and every extra setup that needs to be done will probably not be run/done.

It needs to run very early, because the errors that occur due to such a mistake will be incomprehensible at best.

@ebroto
Copy link
Member

ebroto commented May 26, 2020

I'm thinking if after merging #5636 this could be closed? I'm not sure if it covers point 3, what should be needed in case it does not?

@ebroto
Copy link
Member

ebroto commented Jun 5, 2020

I now see what point 3 means, direct dependencies should re-export the transitive dependency with multiple versions so that the top level crate is able to see both versions.

In that case the issue should remain open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-cargo Type: cargo related
Projects
None yet
Development

No branches or pull requests

4 participants