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.
The new version of tar enables the creation of sparse tar archives by
default. The ability to read such sparse entries was added in tar
0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12.
Additionally, `docker cp` doesn't support sparse tar entries in the GNU
format. For compatibility with older versions of Rust and Cargo, as
well as with `docker cp`, this commit disables sparse archive creation
in the corresponding cases where the `tar::Builder` is used. See
#14594.
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`.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
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.
