fix(resolve): With `latest` message, differentiate actionable updates
### What does this PR try to resolve?
Instead of always listing the absolutely latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
### How should we test and review this PR?
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
### Additional information
This is not intended as *the* solution for #13908 though it experiments with what to do for that.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
Instead of always listing the absolute latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
This is not intended as *the* solution for #13908 though it makes
improvements in that direction.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
fix(resolve): Dont show locking workspace members
### What does this PR try to resolve?
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
### How should we test and review this PR?
### Additional information
This builds on #14440
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
`-Ztarget-applies-to-host --config target-applies-to-host=false` make it
possible to build two units for the same output directory with different
rustflags (one with artifact/target rustflags, one with none/host rust
flags). Those flags aren't included in the `-Cmetadata` hash which is
used to disambiguate different versions of crates, resulting in a conflict.
The actual error being produced appears to be the result of two invocations
of `rustc` racing and clobbering each other.
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
This builds on the prior work to consolidate everything, simplifying the
code and making it clearer what behavior differences exist between
change kinds.
fix: doctest respects Cargo's color options
### What does this PR try to resolve?
Explain the motivation behind this change.
This commit fixes the issue where cargo's test command doesn't respect the color parameter when it gets passed in like this command: `cargo t --color never --doc -- --color never`
Fixes#14403
### How should we test and review this PR?
Test on a basic rust project, with a file called lib.rs that looks like this
```
/// ```
/// bar
/// ```
pub fn foo() {}
#[cfg(test)]
mod tests {
#[test]
fn foo() {
bar
}
}
```
You can try to replicate the same commands `@zacknewman` used in the description of this issue.
`cargo t --color never --doc -- --color never`
You will see that compared to the official build of cargo, this build will respect the --color argument
Be more permissive while packaging unpublishable crates.
This PR allows for packaging workspaces that include `publish = false` crates, in some circumstances:
- unpublishable crates are ignored when inferring the publish registry
- when checking whether the publish registry is valid, we ignore unpublishable crates
- we don't put unpublishable crates in the local registry overlay, so if any workspace crates depend on an unpublishable crate then they will fail to verify.
This PR also contains a refactor, moving the registry inference logic to `registry/mod.rs`, where it will be reused by the upcoming publish-workspace feature. I put the refactor and the logic changes in different commits.
Fixes#14356
This changes the registry validation slightly, adding in a check
forbidding implicit source replacement. This affects the tests (which
configure a dummy registry for source replacement), so we also weaken
the checks by only erroring for registry issues when there are actually
local dependencies.
feat(update): Report when incompatible-rust-version packages are selected
### What does this PR try to resolve?
In discussin this in #13873, it highlighted that we need to make sure we
tell people when incompatible-rust-version packages are selected.
I decided to keep "latest" and "required rust version" messages mutually
exclusive to avoid too much noise. I gave "required rust version"
higher precedence as its the more critical to operation and, if you are
using an MSRV-incompatible package, it likely is "latest" already.
### How should we test and review this PR?
### Additional information
I was tempted to change colors to make "required rust version" stand out
from "latest" but was unsure what direction to go, so I held off.
Options included
- red for "required rust version", yellow for "latest"
- yellow for "required rust version", nothing for "latest"
There is also more discussion on how to format "latest" at #13908.
In discussin this in #13873, it highlighted that we need to make sure we
tell people when we get in this state.
I decided to keep "latest" and "required rust version" messages mutually
exclusive to avoid too much noise. I gave "required rust version"
higher precedence as its the more critical to operation and, if you are
using an MSRV-incompatible package, it likely is "latest" already.
I was tempted to change colors to make "required rust version" stand out
from "latest" but was unsure what direction to go, so I held off.
Options included
- red for "required rust version", yellow for "latest"
- yellow for "required rust version", nothing for "latest"
There is also more discussion on how to format "latest" at #13908.
Add `--lockfile-path` flag
This change implements a new `--lockfile-path` proposed in #5707 .
Functionality added:
- Add `--lockfile-path <PATH>` to all commands that support `manifest-path` with exception of:
- `locate-project` (doesn't use lock file)
- `verify-project` (is deprecated)
- `read-manifest` (doesn't use lock file)
- Behind -Zunstable-options and docs
- The flag's docs / `--help` has (unstable) in them
- `<PATH>` must end with `Cargo.lock`. If specified path doesn't exist (or parent director(ies), create all the parent directories and the lockfile itself
Implementation TLDR: add `requested_lockfile_path` into `Workspace` and set it on `workspace(gctx)` call (setting from the context)
Update `lockfile.lock_root()` to respect `requested_lockfile_path` (if set)
Add test cases covering all affected commands. Tested creating lockfile, reading lockfile, overriding default (`./Cargo.lock`) lockfile, symlink tests. Extra tests for package to make sure pinned versions from path's lockfile are respected (i.e. double check correct lockfile is used)
I doubt this flag will be used for any command that's not read-only, but I tried to cover all the commands.
test: Migrate some json tests to snapbox
### What does this PR try to resolve?
This is part of #14039
### How should we test and review this PR?
### Additional information
This was unblocked because of assert-rs/snapbox#350
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.
