Package collision in the lockfile

[ndmitchell]

trafficstars

Thanks for outdated - it's super useful - and I've used it successfully in the past. However, today, running the latest version of cargo outdated (installed 10 mins ago) I get the error:

$ error: package collision in the lockfile: packages foo v0.1.0 (/Users/me/code/foo/foo) and foo v0.1.0 (/var/folders/pb/6c07r1td0_5465/T/cargo-outdatedBB/foo/foo) are different, but only one can be written to lockfile unambiguously

This is using a private codebase, where foo is not really foo but a different internal package. That package foo is used by about 7 projects with a workspace. None of these constrain the version. Any idea what causes this condition? Any way to improve the error to indicate what the problem might be? Any useful information I can provide?

[deg4uss3r]

If I understand correctly you have an internal crate with the same name as another dependency? Basically this happens when a crate with the same name is used in the same workspace with the same version but they are different crates.

This is a cargo feature actually. You can see a simple test here in the cargo source code.

[ndmitchell]

It's not that I have the same name twice - it's all unique. The problem is that I refer to the same project under two different paths. I put together a simplified test case at: https://github.com/ndmitchell/cargo-outdated-bug-239. Get that repo, cd project then:

C:\Neil\temp\cargo-outdated-bug-239\project>cargo outdated
error: package collision in the lockfile: packages c v1.0.0 (C:\Neil\temp\cargo-outdated-bug-239\project\c) and c v1.0.0 (C:\Users\NDMIT_~1\AppData\Local\Temp\cargo-outdated6bWfEH\c) are different, but only one can be written to lockfile unambiguously

I refer to c as ../c in one dependency, and ../../project/c in the other - these both refer to the same path on disk, but something in cargo outdated thinks they are two distinct copies. In my particular example the second dependency is in a different project, so the real path of a is project2/a - so it's not possible to normalise the paths to be the same sensibly.

[deg4uss3r]

Thanks so much! This very helpful I'll see if we can work on a fix for this, it appears to be pulling in the direct path and a path from the tmp director which is causing the error.

[sofusmortensen]

In the particular test case https://github.com/ndmitchell/cargo-outdated-bug-239 the problem is not that we have two references to c but that the reference ../../project/c going out of project and back in is going to be invalid in the temp directory structure created, as root project directory project does not exist there by that name.

I can offer a fix to this problem by having cargo-outdated normalise dependencies, reducing ../../project/c to just ../c.

A related issue is this: https://github.com/kbknapp/cargo-outdated/issues/285