You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using sparse-registry with an alternative registry, the SourceID is rendered as registry+sparse+https://.... That doesn't look correct to me, I would assume it should be sparse+https://….
Steps
The following cargo test illustrates the example where the SourceID gets shown to the user.
#[cargo_test]fnsparse_alt_registry(){let _server = RegistryBuilder::new().http_index().alternative().build();let p = project().file("Cargo.toml",r#" [project] name = "foo" version = "0.0.1" authors = [] [dependencies] bar = {registry="alternative", version=">= 0.0.0"} "#,).file("src/main.rs","fn main() {}").build();Package::new("bar","0.0.1").alternative(true).publish();cargo_http(&p,"build --message-format=json")// SourceID issue is here....with_stderr("").run();}
Here the JSON will have things like "package_id":"bar 0.0.1 (registry+sparse+http://127.0.0.1:61095/index/)"
Possible Solution(s)
The issue is that the serialization code here doesn't know anything about sparse registries.
My intuition is that SourceKind should have another variant to track sparse indexes (instead of reusing SourceKind::Registry). This is related to the comment here about it being a little strange that sparse+ is being tacked into the URL.
Notes
I would also like to see more tests for alt registries using sparse registries.
Version
cargo 1.64.0-nightly (85b500cca 2022-07-24)
release: 1.64.0-nightly
commit-hash: 85b500ccad8cd0b63995fd94a03ddd4b83f7905b
commit-date: 2022-07-24
host: x86_64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.4.0 [64-bit]
The text was updated successfully, but these errors were encountered:
Problem
When using sparse-registry with an alternative registry, the SourceID is rendered as
registry+sparse+https://...
. That doesn't look correct to me, I would assume it should besparse+https://…
.Steps
The following cargo test illustrates the example where the SourceID gets shown to the user.
Here the JSON will have things like
"package_id":"bar 0.0.1 (registry+sparse+http://127.0.0.1:61095/index/)"
Possible Solution(s)
The issue is that the serialization code here doesn't know anything about sparse registries.
My intuition is that
SourceKind
should have another variant to track sparse indexes (instead of reusing SourceKind::Registry). This is related to the comment here about it being a little strange thatsparse+
is being tacked into the URL.Notes
I would also like to see more tests for alt registries using sparse registries.
Version
The text was updated successfully, but these errors were encountered: