This was mostly done by clippy via `clippy::doc_markdown`.
I then reviewed it to fix words that shouldn't have it or where `--fix`
put the backtick in the wrong location.
I'm unsure how we should be replacing these use cases, so I'm exploring
keeping them but making them use snapbox under the hood.
Part of the intent of snapbox is that it provides you the building
blocks to make what you need.
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
This is to bring us into conformance with the [Rust crate ownership
policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo-credential-1password` is declared as Experimental as it is
intended for the community but I was unsure if we wanted to commit to
full support for it. In my mind, the ideal thing to do would be to
expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the
ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended
for the wider ecosystem and I didn't see a reason to declare it
experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared
as Intentional as they are both used internally and intended for
others to use for logic that integrates with cargo/registries.
I wondered about these being Experimental or Internal instead.
I'm intentionally being light as I want to pull in a lot of "lessons
learned" from the port to snapbox into the docs and want that as a
dedicated PR to make it easier for the contributors to that effort to
review it.
fix(test)!: Clarify extension trait role with rename
When browsing the docs, I feel like this will make it easier to tell the role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
When browsing the docs, I feel like this will make it easier to tell the
role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and
for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
I was considering moving this into `paths` and noticed `CargoPathExt`.
I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
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.
