This is different from previous posts about this issue because this time I can't make out any pinned versioning of the conflicted crate. Running
cargo update -p proc-macro2 updated the crate
proc-macro2 v1.0.39 -> v1.0.47 and then the build started working again.
error: failed to select a version for `proc-macro2`. ... required by package `clap_derive v4.0.21` ... which satisfies dependency `clap_derive = "=4.0.21"` of package `clap v4.0.26` ... which satisfies dependency `clap = "^4.0"` (locked to 4.0.26) of package `mycrate` ... which satisfies path dependency `mycrate` of package `mypackage` versions that meet the requirements `^1.0.42` are: 1.0.47, 1.0.46, 1.0.45, 1.0.44, 1.0.43, 1.0.42 all possible versions conflict with previously selected packages. previously selected package `proc-macro2 v1.0.39` ... which satisfies dependency `proc-macro2 = "^1"` (locked to 1.0.39) of package `actix-web-codegen v4.0.1` ... which satisfies dependency `actix-web-codegen = "^4"` (locked to 4.0.1) of package `actix-web v4.1.0` ... which satisfies dependency `actix-web = "^4"` (locked to 4.1.0) of package `actix-files v0.6.1` ... which satisfies dependency `actix-files = "^0.6.1"` (locked to 0.6.1) of package `anothercrate` ... which satisfies path dependency `anothercrate` (locked to 0.0.0) of package `mypackage` failed to select a version for `proc-macro2` which could resolve this conflict
Can't Cargo could automatically update packages in this scenario to make them satisfy constraints?
The carat (
^0.0.0) syntax does allow the crate to be updated till
^0.0.z in the scenario that patch version is specified, which seems to be the case here.