Unexpected `failed to select a version for the requirement` for workspace `cargo release publish`
We're considering switching to cargo-release to perform the publish part of our two-stage release process.
I just ran a dry-run cargo release publish locally on a branch with this change checked out:
https://github.com/heroku/libcnb.rs/pull/690
And got this error:
$ cargo release publish
Publishing libcnb-common
Updating crates.io index
Packaging libcnb-common v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-common)
Packaged 6 files, 5.1KiB (2.5KiB compressed)
Uploading libcnb-common v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-common)
warning: aborting upload due to dry run
Publishing libcnb-proc-macros
Updating crates.io index
Packaging libcnb-proc-macros v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-proc-macros)
Packaged 5 files, 8.0KiB (3.0KiB compressed)
Uploading libcnb-proc-macros v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-proc-macros)
warning: aborting upload due to dry run
Publishing libcnb-data
Updating crates.io index
Packaging libcnb-data v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-data)
Packaged 24 files, 87.5KiB (17.8KiB compressed)
Uploading libcnb-data v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-data)
warning: aborting upload due to dry run
Publishing libcnb
Updating crates.io index
Packaging libcnb v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb)
Packaged 23 files, 170.8KiB (36.4KiB compressed)
Uploading libcnb v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb)
warning: aborting upload due to dry run
Publishing libcnb-package
Updating crates.io index
Packaging libcnb-package v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-package)
Packaged 15 files, 50.1KiB (12.8KiB compressed)
Uploading libcnb-package v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-package)
warning: aborting upload due to dry run
Publishing libcnb-test
Updating crates.io index
Packaging libcnb-test v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-test)
Packaged 17 files, 91.0KiB (19.3KiB compressed)
Uploading libcnb-test v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-test)
warning: aborting upload due to dry run
Publishing libcnb-cargo
Updating crates.io index
Packaging libcnb-cargo v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-cargo)
Updating crates.io index
error: failed to prepare local package for uploading
Caused by:
failed to select a version for the requirement `libcnb-data = "=0.15.0"`
candidate versions found which didn't match: 0.14.0, 0.13.0, 0.12.0, ...
location searched: crates.io index
required by package `libcnb-cargo v0.15.0 (/Users/emorley/src/libcnb.rs/libcnb-cargo)`
perhaps a crate was updated and forgotten to be re-vendored?
What seems strange to me (and potentially a cargo-release bug), is that the crate in question (libcnb-data v0.15.0) is already "dry run published" earlier in the command output - so the 0.15.0 version should have been found whilst processing libcnb-cargo?
Also, several other of the crates that succeeded during the dry-run also depend upon libcnb-data, but they did not fail. The libcnb-cargo crate is a binary crate, so could that be the difference?
As far as I know, there are no circular dependencies.
I tried using --no-verify but that didn't help either.
This was using:
$ rustc --version
rustc 1.73.0-beta.7 (7c76587ed 2023-09-22)
$ cargo release --version
cargo-release 0.24.12
The problem is we are trying to get cargo publish to do something it isn't designed for. rust-lang/cargo#1169 is the upstream issue that would get this to work.
Hi! Thank you for the reply :-)
However, I'm a bit confused. Reading your reply (specifically the https://github.com/rust-lang/cargo/issues/1169 is the upstream issue that would get this to work part) it sounds like you are saying "cargo release doesn't support dry run of workspaces, so it's not a bug", but you also added the bug label? Plus cargo-release does support inferring the soon-to-be-published packages in many cases (just not this specific crate in the graph) - so it doesn't seem like it's not supported at all?
I'm saying that what we do is very limited by what cargo publish can do. We already hack around other problems by implicitly adding --no-verify to dry-run. We could possibly go a step further and implicitly not run cargo publish as part of dry run.
We could also more thoroughly fix this but the work but into that would best instead be done in cargo instead, hence the issue.