Problem
#13447 dd698ff has some unintentional consequences:
cargo package after that generates a lockfile also when packaging libraries.
However, if the crate being packaged depends on some unpublished dependencies. When generating the lockfile Cargo then can't find unpublished deps on registry index, so it bailed out.
Steps
This could be simplly reproduced in rust-lang/cargo as of today (2025-01-13)
- Checkout to 54df3c7
- Bump cargo-test-support to an unpublished version such as
99.99.99
cargo +1.83.0 package -p cargo-test-support --no-verify — succeededcargo +1.84.0 package -p cargo-test-support --no-verify — failed
Possible Solution(s)
Assume if we have passed the local registry unconditionally, we shouldn't have the issue today.
|
let mut local_reg = if ws.gctx().cli_unstable().package_workspace { |
|
let reg_dir = ws.target_dir().join("package").join("tmp-registry"); |
|
sid.map(|sid| TmpRegistry::new(ws.gctx(), reg_dir, sid)) |
|
.transpose()? |
|
} else { |
|
None |
|
}; |
Version
cargo 1.84.0 (66221abde 2024-11-19)cargo 1.86.0-nightly (088d49608 2025-01-10)
Problem
#13447 dd698ff has some unintentional consequences:
cargo packageafter that generates a lockfile also when packaging libraries.However, if the crate being packaged depends on some unpublished dependencies. When generating the lockfile Cargo then can't find unpublished deps on registry index, so it bailed out.
Steps
This could be simplly reproduced in rust-lang/cargo as of today (2025-01-13)
99.99.99cargo +1.83.0 package -p cargo-test-support --no-verify— succeededcargo +1.84.0 package -p cargo-test-support --no-verify— failedPossible Solution(s)
Assume if we have passed the local registry unconditionally, we shouldn't have the issue today.
cargo/src/cargo/ops/cargo_package/mod.rs
Lines 219 to 225 in f15df8f
Version
cargo 1.84.0 (66221abde 2024-11-19)cargo 1.86.0-nightly (088d49608 2025-01-10)