This is a partial revert of ##14121
(e11d1722bb6e1e58c91adb1964993c74b45f4293)
Our focus for redacting (auto or with globs) includes
- run-specific information (timing, hashes, platform-specific wording)
- rustc-specific information
(We tend to use globs for rustc-specific information because there might
be some very specific times we need to care about some of the details)
However, "Packaged files" does not fit into any of that and, for now, we
are erring on the side of redacting less, rather than more, with the
move to snapbox.
As we see how it works out and what the underlying requirements are, we
can revisit this.
Once we support packaging workspaces with dependencies, dependency
packages need to be built before anything is verified. In addition to a
little refactoring, this commit reorders the console messages so that
package metadata (archive size, etc.) is reported before verification
results.
Co-Authored-By: Tor Hovland <55164+torhovland@users.noreply.github.com>
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
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.
