vergen-gitcl 9.1.0 is broken

[ReDestroyDeR]

Hello

vergen-gitcl's dependency tree is broken

~ cargo tree -i vergen-lib@9.1.0
vergen-lib v9.1.0
└── vergen v9.1.0
    └── vergen-gitcl v1.0.8
        └── YYY
            [build-dependencies]
            └── XXX
~ cargo tree -i vergen-lib@0.1.6
vergen-lib v0.1.6
└── vergen-gitcl v1.0.8
    └── YYY
        [build-dependencies]
        └── XXX

it depdens on vergen-lib 1.08, while simultaniously depending on vergen 9.1.0

for example it breaks trait implementation for Gitcl type

|             .add_instructions(&rustc)?
|                               ^^^^^^ the trait `vergen_lib::entries::Add` is not implemented for `vergen::feature::rustc::Rustc`

[ReDestroyDeR]

as a workaround I pinned older versions

vergen-gitcl = "=1.0.8"
vergen = "=9.0.6"
vergen-lib = "=0.1.6"

[CraZySacX]

Still trying to figure out how this is happening. I have another project where I use vergen-gix myself and the same issues happens when I use the older version 1.0.9 of that. cargo is somehow pulling in the 9.1.0 version of the library as well as the actual dependency.

[CraZySacX]

Ok, seems like cargo allows multiple concurrent versions of transitive dependencies (in this case vergen-lib) when at least one of the versions is in the unstable 0.x.x range. Because vergen-lib migrated to a "stable" release version this causes the error. I think the only solution if you want to continue using the 1.x version is what you did, explicitly pinning. If you explicitly make the version 9.1.0 for the library this issue is also resolved.

[pronebird]

What happened, why was versioned bumped from 1.x to 9.x?

[ReDestroyDeR]

What happened, why was versioned bumped from 1.x to 9.x?

I suppose vergen-gitcl doesn't have Cargo.lock, which is to be expected, and vergen-gitcl transitively got two versions of vergen-lib one from vergen and another one from cargo.toml

[CraZySacX]

What happened, why was versioned bumped from 1.x to 9.x?

I was maintaining independent versions for each binary and it was becoming a bit of admin hell tracking tags and releases so I synced all of the versions to the new latest. The plan is to keep all versions across all Cargo.toml in sync for each update. I can see this might not accurately reflect changes in each binary, so I may end up splitting everything up into separate repositories if the single repo-wide version becomes an issue as well.

[pronebird]

Ok got it, thanks. I was a bit concerned that something else was at play. 👍

[alerque]

I just hit this too on a vergen-gix dependency. I tried bumping some stuff in the lockfile (not the manifest) and it added vergen 9.1 and started throwing the same error as above.

[iximeow]

Ok, seems like cargo allows multiple concurrent versions of transitive dependencies (in this case vergen-lib) when at least one of the versions is in the unstable 0.x.x range

this is generally true regardless of the versions of transitive dependencies; if dependency A requires C = "=1.0.2" and dependency B requires C = "=1.0.3" then you'll have both 1.0.2 and 1.0.3 in a Cargo.lock to satisfy both.

the issue here is that going from 9.0.6 to 9.1.0 is a minor bump by Cargo standards, those versions should be semver-compatible. so if you cargo update -p vergen it'll update an existing 9.0.6 dependency to 9.1.0. that comes with the bump of vergen-lib to 9.1.0, but in our case (w/ oxidecomputer/propolis#1070) vergen-git2 is at 1.0.7 and uses the different major version vergen-lib = "0.1.6". so types in vergen-git2 implement vergen-lib@0.1.6 traits while being passed to the vergen-exported functions of vergen-lib wanting impls of vergen-lib@9.1.0 traits.

you might not have noticed this before because as long as the -lib crate differs only in minor versions and no one is doing vergen-lib = "=<specific.version>", Cargo will pick a version of the library crate that satisfies everyone's requirements. all the dependents will happen to implement the same version of the library traits.

I've found that the least annoying way to manage crate groups like this is that if a crate mentions another crate's types in its public API, and the other crate has a major version bump, the first crate must also have a major version bump to avoid situations like this. I also think cargo-semver-checks would lint on a major version bump of a dependency like this, if you haven't tried that out before!

relatedly, if you update vergen to 9.1.0 along with vergen-{git2,gitcl,gitx} (whichever you're using) it'll all be happy again. or pinning to older versions works too. we'll probably end up going to 9.1.0 :)