This enables rustdoc invocation from `cargo doc` to trim paths
in diagnostics. Doc tests are out-of-scope, as they are handled
in a different mechanism, which needs more cares.
feat: Add `info` cargo subcommand
<!-- homu-ignore:start -->
close https://github.com/rust-lang/cargo/issues/14081
close https://github.com/rust-lang/cargo/issues/948
fcp https://github.com/rust-lang/cargo/pull/14141#issuecomment-2243683924
This PR added a new `info` cargo subcommand.
# Background
This adds a new subcommand to Cargo, `cargo info`. This subcommand would allow users to get information about a crate from the command line, without having to go to the web.
The main motivation for this is to make it easier to get information about a crate from the command line. Currently, the way to get information about a crate is to go to the web and look it up on [crates.io] or find the crate's source code and look at the `Cargo.toml` file. This is not very convenient, especially not all information is displayed on the [crates.io] page.
This command also has been requested by the community for a long time. You can find more discussion about this in [cargo#948].
Another motivation is to make the workflow of finding and evaluating crates more efficient. In the current workflow, users can search for crates using `cargo search`, but then they have to go to the web to get more information about the crate. This is not very efficient, especially if the user is just trying to get a quick overview of the crate. This would allow users to quickly get information about a crate without having to leave the terminal.
[crates.io]: https://crates.io
[cargo#948]: https://github.com/rust-lang/cargo/issues/948
Example usage:
```console
./target/debug/cargo info clap --verbose
Credential cargo:token get crates-io
clap #argument #cli #arg #parser #parse
A simple to use, efficient, and full-featured Command Line Argument Parser
version: 4.5.8 (latest 4.5.9)
license: MIT OR Apache-2.0
rust-version: 1.74
documentation: https://docs.rs/clap/4.5.8
repository: https://github.com/clap-rs/clap
crates.io: https://crates.io/crates/clap/4.5.8
features:
+default = [std, color, help, usage, error-context, suggestions]
color = [clap_builder/color]
error-context = [clap_builder/error-context]
help = [clap_builder/help]
std = [clap_builder/std]
suggestions = [clap_builder/suggestions]
usage = [clap_builder/usage]
cargo = [clap_builder/cargo]
debug = [clap_builder/debug, clap_derive?/debug]
deprecated = [clap_builder/deprecated, clap_derive?/deprecated]
derive = [dep:clap_derive]
env = [clap_builder/env]
string = [clap_builder/string]
unicode = [clap_builder/unicode]
unstable-doc = [clap_builder/unstable-doc, derive]
unstable-styles = [clap_builder/unstable-styles]
unstable-v5 = [clap_builder/unstable-v5, clap_derive?/unstable-v5, deprecated]
wrap_help = [clap_builder/wrap_help]
dependencies:
+clap_builder@=4.5.8
clap_derive@=4.5.8
owners:
kbknapp (Kevin K.)
github:rust-cli:maintainers (Maintainers)
github:clap-rs:admins (Admins)
note: to see how you depend on clap, run `cargo tree --invert --package clap@4.5.8`
```
<img width="1425" alt="image" src="https://github.com/user-attachments/assets/e0813c45-624f-417c-a61d-eda03f9ab5ed">
*note:* this is showing the `--verbose` output to show every thing the user can possibly see. Normal operation does not include
- dependencies
## Detailed design
| Content | Explanation | Why |
|----------------------------------------------------------------------------|-------------------------------------|-----------------------------------------------------------------------------------|
| clap | Name | The basic information. |
| #argument #cli #arg #parser #parse | Keywords (clickable) | It's more like a category, which you can use to search for relevant alternatives. |
| A simple to use, efficient, and full-featured Command Line Argument Parser | Description | The basic information. |
| version: 4.5.8 (latest 4.5.9) | Version | The basic information. |
| license: MIT OR Apache-2.0 | License | When choosing a crate, it is crucial to consider the license. |
| rust-version: 1.74 | MSRV | When choosing a crate, it is crucial to make sure it can work with your MSRV. |
| documentation: <https://docs.rs/clap/4.5.8> | Documentation Link | Use these links can find more docs and information. |
| repository: <https://github.com/clap-rs/clap> | Repo Link | Use these links can find more docs and information. |
| crates.io: https://crates.io/crates/clap/4.5.8 | crates.io Link | Use these links can find more docs and information. |
| features: | Default Features And Other Features | It helps for enabling features. |
| dependencies: | All dependencies | It indicates what it depends on. |
| owners: | Owners | It indicates who maintains the crate. |
| note: to see how you depend on clap, run `cargo tree --invert --package clap@4.5.8` | A note for cargo tree command | It will prompt the user that the package is depended on under the workspace, and the dependencies can be viewed using the cargo tree command. |
## Rendering features
- For features enabled by users, a + prefix and colored output are now used for better visibility.
- For features enabled automatically, colored output is used to distinguish them.
- For disabled features, non-colored output is used to clearly indicate their status.
## Rendering deps
Only show dependencies in verbose mode.
- For dependencies required by the package, a + prefix and colored output are now used for better visibility.
- For dependencies that are optional and activated, colored output is used to distinguish them.
- For dependencies that are optional and not activated, non-colored output is used to clearly indicate their status.
# Some important notes
## Downloading the crate from any Cargo compatible registry
The `cargo info` command will download the crate from any Cargo compatible registry. It will then extract the information from the `Cargo.toml` file and display it in the terminal.
If the crate is already in the local cache, it will not download the crate again. It will get the information from the local cache.
## Pick the correct version from the workspace
When executed in a workspace directory, the cargo info command chooses the version that the workspace is currently using.
If there's a lock file available, the version from this file will be used. In the absence of a lock file, the command attempts to select a version that is compatible with the Minimum Supported Rust Version (MSRV). And the lock file will be generated automatically.
The following hierarchy is used to determine the MSRV:
- First, the MSRV of the parent directory package is checked, if it exists.
- If the parent directory package does not specify an MSRV, the minimal MSRV of the workspace is checked.
- If neither the workspace nor the parent directory package specify an MSRV, the version of the current Rust compiler (rustc --version) is used.
# Prior art
## NPM
[npm] has a similar command called `npm info`.
For example:
```console
$ npm info lodash
lodash@4.17.21 | MIT | deps: none | versions: 114
Lodash modular utilities.
https://lodash.com/
keywords: modules, stdlib, util
dist
.tarball: https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz
.shasum: 679591c564c3bffaae8454cf0b3df370c3d6911c
.integrity: sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==
.unpackedSize: 1.4 MB
maintainers:
- mathias <mathias@qiwi.be>
- jdalton <john.david.dalton@gmail.com>
- bnjmnt4n <benjamin@dev.ofcr.se>
dist-tags:
latest: 4.17.21
published over a year ago by bnjmnt4n <benjamin@dev.ofcr.se>
```
[npm]: https://www.npmjs.com/
## Poetry
[Poetry] has a similar command called `poetry show`.
For example:
```console
$ poetry show pendulum
name : pendulum
version : 1.4.2
description : Python datetimes made easy
dependencies
- python-dateutil >=2.6.1
- tzlocal >=1.4
- pytzdata >=2017.2.2
required by
- calendar >=1.4.0
```
[Poetry]: https://python-poetry.org/
# insta-stable
As `@weihanglo` mentioned in https://github.com/rust-lang/cargo/pull/14141#issuecomment-2189223552, commands that shadow third-party commands tend to be insta-stabilized to avoid an intermediate period where users can't access the third-party command (built-ins get priority) nor the built-in command (requires nightly)
For the cargo-info command, there are two commands that this would shadow
- [cargo-information](https://github.com/hi-rustin/cargo-information): hasn't been around too long and only has 4k downloads
- [cargo-info](https://gitlab.com/imp/cargo-info) : been around longer and has 63k downloads
We might be able to get away with having this unstable but starting from the assumption of insta-stabilization.
CI: Switch macos aarch64 to nightly
We will be promoting aarch64-apple-darwin to tier 1 soon via https://github.com/rust-lang/rust/pull/128592. This updates our CI so that aarch64-apple-darwin runs the full test suite on nightly to keep this in-line with tier-1 support.
This also removes the x86_64 stable macos job and replaces it with aarch64, mainly because aarch64 runs much faster, and presumably x86_64 support will go away some day.
We will be promoting aarch64-apple-darwin to tier 1 soon via
https://github.com/rust-lang/rust/pull/128592. This updates our CI
so that aarch64-apple-darwin runs the full test suite on nightly to
keep this in-line with tier-1 support.
This also removes the x86_64 stable macos job and replaces it with
aarch64, mainly because aarch64 runs much faster, and presumably
x86_64 support will go away some day.
Use context instead of with_context
Replace `.with_context(|| "…")` with `.context("…")` to avoid calling a trivial closure. It is also shorter :)
On the other hand, use `.with_context(|| format!(…))` instead of `.context(format!(…))` to avoid unneeded string allocation.
Fix: `cargo package` failed on bare commit git repo.
### What does this PR try to resolve?
Fixes#14354
This approach chose to not generate a `.cargo_vcs_info.json` for bare commit git repo.
### How should we test and review this PR?
Compare the test changes before and after the two commits
### Additional information
fix: std Cargo.lock moved to `library` dir
https://github.com/rust-lang/cargo/pull/14358 didn't check the correct Cargo.lock existence
Perhaps it was there so the test passed,
but after a new nightly is out it is gone.
```
Blocking waiting for file lock on package cache
error: "/home/user/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
rustup component add rust-src --toolchain nightly-aarch64-apple-darwin
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Fixes https://github.com/rust-lang/rust/issues/128808
### How to test the change:
The current nightly `cargo 1.82.0-nightly (94977cb1f 2024-08-06)` would fail when running
```
cargo +nightly build -Zbuild-std --target <host-triple>
```
After this fix, it should just work
```
RUSTC=~/.rustup/toolchains/nightly-<host-triple>/bin/rustc ./target/debug/cargo build -Zbuild-std --target <host-triple>
```
rust-lang/cargo#14358 didn't check the correct Cargo.lock existence
Perhaps it was there so the test passed, but after a new nightly
is out it is gone.
```
Blocking waiting for file lock on package cache
error: "/home/user/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
rustup component add rust-src --toolchain nightly-aarch64-apple-darwin
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
fix(vendor): Strip excluded build targets
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/14348
### How should we test and review this PR?
The commits are setup to be able to show, through the tests, how the `cargo package` and `cargo vendor` behavior diverge and then how `cargo vendor`s behavior changes over time.
This is a **very** hacky solution, duplicating the minimum of what
`prepare_for_publish` does to fix this one issue and in the least
intrusive way to the vendor code.
The intention is to keep this low risk for backporting to beta and
stable.
We need to revisit this, refactoring the `cargo package` code so that we
can call into that for each vendored dependency.
### Additional information
This is a **very** hacky solution, duplicating the minimum of what
`prepare_for_publish` does to fix this one issue and in the least
intrusive way to the vendor code.
The intention is to keep this low risk for backporting to beta and
stable.
We need to revisit this, refactoring the `cargo package` code so that we
can call into that for each vendored dependency.
Fixes#14348
Since we already cover this for `cargo package` and we turn all
implicit targets into explicit targets (making implicit tests cover
explicit cases), this becomes redundant.
Infer registry
While working on `cargo publish` for workspaces, I noticed a few ways in which the registry inference for `cargo package` seemed wrong. (This only affects the unstable `-Zpackage-workspace` feature.) This is all about the interaction between `--index`/`--registry`, and the `package.publish` fields.
- Previously, if multiple crates were packaged and they had different `package.publish` settings, we would ignore those setting and fall back to "crates-io". After this PR, we will bail out with an error instead (unless they've specified `--registry` or `--index`).
- Previously, we would validate the inferred registry against the `package.publish` settings, even if the `--index` argument would have taken precedence. After this PR, we will skip registry validation in this case.
- Previously, we were just ignoring the registry value inferred from `package.publish`: we'd validate that it was ok, but then just not use it.
Don't specify the depedency name in the `cargo add` inferred name test
The `cargo_add/path_inferred_name` was incorrectly adding the name of the dependency to add in its command line.
Starting from rust-lang/rust#128534 (nightly-2024-08-05),
stnadard library has its own Cargo workspace.
Hence `-Zbuild-std` no longer need to fake a virtual workspace.
This also adjusts Cargo.toml in `mock-std` to align with std's Cargo.toml
refactor(toml): Rename 'resolved' to 'normalized'
In a discussion on an issue, it became confusing to talk about "resolved" manifests and dependency resolution,
so I'm switching manifests to use the other term I considered, "normalized".
faq: rephrase offline usage.
### What does this PR try to resolve?
fixes#14330. FAQ tried to explain the history of cargo offline, and thus
was distracting from the core flags.
