In `alt_registry::warn_for_unused_fields`, the second part of the test
runs on `--registry crates-io`, so it needs a local replacement url.
In `install::install_global_cargo_config`, it was adding to the "config"
file, but the `pkg` before it configured the dummy registry replacement
in "config.toml". So that replacement wasn't actually used, and if you
ran tests online it was trying to install `bar v0.1.1` from the real
registry! The filename is now fixed, and the test double-checks that
we're only trying to install the local `bar v0.0.1`.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
fix(metadata): Stabilize id format as PackageIDSpec
### What does this PR try to resolve?
For tools integrating with cargo, `cargo metadata` is the primary interface. Limitations include:
- There isn't an unambiguous way to map a package entry from `cargo metadata` to a parameter to pass to other `cargo` commands. An `id` field exists but it is documented as an opaque string, useful only for comparisons with other `id`s within the document.
- There isn't an unambiguous way of taking user parameters (`--package`) and mapping them to `cargo metadata` entries. `cargo pkgid` could help but it returns a `PackageIdSpec` which doesn't exist within the `cargo metadata` output.
This attempts to solve these problems by switching the `id` field from `PackageId` to `PackageIdSpec` which is a [publicly documented format](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), can be generated by `cargo pkgid`, and is accepted by most commands via the `--package` flag.
As the `"id"` field is documented as opaque, this technically isn't a breaking change though people could be parsing it.
For `cargo_metadata` they do [use a new type that documents it as opaque but publicly expose the inner `String`](https://docs.rs/cargo_metadata/latest/cargo_metadata/struct.PackageId.html). The `String` wasn't publicly exposed due to a request by users but instead their `PackageId` type replaced using `String`s in the API in oli-obk/cargo_metadata#59 with no indication given as to why the `String` was still exposed. However, you'll note that before that PR, they had `WorkspaceMember` that parsed `PackageId`. This was introduced in oli-obk/cargo_metadata#26 without a motivation given.
**Note that `PackageIdSpec` has multiple representation that might uniquely identify a package and we can return any one of them.**
Fixes#7267
### How should we test and review this PR?
### Additional information
cc `@oli-obk`
This was allowed when switching from `toml` v0.5 to `toml_edit` which
started allowing empty keys when parsing TOML.
This mirrors the change
we made for disallowing empty feature names in #12928.
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
When doing a credential lookup, Cargo deserializes the registry configuration and detects the
registries.crates-io.protocol key as unused and issues a warning.
This fixes the issue by adding the field to the struct
Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.
This makes it easier to write tests that deal with authentication and
http registries.
During the design conversations on cargo-add, we noticed that
`cargo-install` has a public flag `--version` and an invisible alias
`--vers` while `cargo-yank` has a public flag `--vers`. This switches
`cargo-yank` to publicly use `--version` and have an invisible alias
`--vers`, making them consistent.
Completions are a best guess.
After the rust_version field was stabilized in #9732 this adds the
rust_version as output to the `cargo metadata` command, so tools like
Clippy can read and use it as well.
