foresterre / cargo-msrv Goto Github PK
View Code? Open in Web Editor NEW๐ฆ Find the minimum supported Rust version (MSRV) for your project
Home Page: https://foresterre.github.io/cargo-msrv
License: Apache License 2.0
๐ฆ Find the minimum supported Rust version (MSRV) for your project
Home Page: https://foresterre.github.io/cargo-msrv
License: Apache License 2.0
Is there supposed to be output for running cargo msrv
? I tried it and followed along with htop
as it worked backwards through rust versions, assuming that when it stopped at 1.44.0 that the last version supported was 1.45.0, but this gets a little confusing, especially if I'm working in multiple projects.
Is there something I missed?
are you also interested in using Clap's declarative syntax for defining the CLI?
Originally posted by @danieleades in #100 (comment)
Improve the --help
text for the --verify
flag.
--verify
Verify the MSRV, if defined with the 'package.metadata.msrv' key in the 'Cargo.toml'. When this flag is
present, cargo-msrv will not attempt to determine the true MSRV. It will only attempt to verify specified
MSRV, the Rust build passes similarly to regular cargo-msrv runs.
I have a project where the MSRV for the tests is not the same as for the binary
We currently always update the index. We should however make this optional (in which case the user bears the responsibility of having an up-to-date index in place at the right location on disk.
NB: the location on disk is currently not configurable, allowing for the location to be changed depends on foresterre/rust-releases#40
|- Dep [1.42.0]
|- Dep2 [1.51.0]
cargo-msrv 1.51.0
package.rust-version
or else package.metadata.msrv
cargo msrv list
Lists the msrv's of all (transitive) dependencies, and computes the MSRV based on these values
--include-dev
--no-transitive
--no-compute-msrv
i.e. currently we show:
cargo-msrv: checking target: <target> on version: <version>
however, during the check two steps take place:
version-target
) if not installedIt would be nice to show the status of each step separately.
is there a reason this isn't the default?
Originally posted by @danieleades in #45 (comment)
When we find a new MSRV, we should be able to add it to the Cargo manifest (Cargo.toml) automatically, saving a user time, similarly to cargo add
etc. from cargo-edit
.
By default:
package.rust-version
for Rust distributions where MSRV >=1.56package.metadata.msrv
for Rust distributions where MSRV <1.56, as Cargo supports the rust-version field only since Rust distributions 1.56 or newer; for earlier versions it will produce an (unwanted) error.TODO's:
--write-manifest-msrv
(feel free to suggest a better name :D) #368Under consideration:
package.rust-version
and package.metadata.msrv
) where we can put the MSRVpackage.rust-version
regardless of the MSRV and warning Cargo will produce for versions <1.56.0.package.metadata.msrv
regardless of the MSRVExample 1:
Given, a found MSRV of version 1.56.0
, and the following manifest:
[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"
[dependencies]
We would write the the found MSRV to the manifest, and produce:
[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"
rust-version = "1.56.0"
[dependencies]
Example 2:
Given, a found MSRV of version 1.55.0
, and the following manifest:
[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"
[dependencies]
We would write the the found MSRV to the manifest, and produce:
[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"
[package.metadata]
msrv = "1.55.0"
[dependencies]
check
should work well enoughcargo check
is a bit faster, especially for larger projectscargo msrv -- cargo build
or cargo msrv -- cargo build --all
The command cargo check --all
externally works, but says: Bad check for 1.55.0
and fails with the above message.
๏ป eww on ๎ current [$โก] via ๏ข v14.17.2 via ๐ฆ v1.56.0-nightly took 1m40s >>> cargo check --all
Checking eww v0.2.0 (/home/animesh/Projects/eww/crates/eww)
Finished dev [unoptimized + debuginfo] target(s) in 10.64s
๏ป eww on ๎ current [$โก] via ๏ข v14.17.2 via ๐ฆ v1.56.0-nightly took 10s >>> cargo msrv
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check --all
Done Bad check for 1.55.0 โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ 00:00:35
Failed check command cargo check --all didn't succeed
Unable to find a Minimum Supported Rust Version (MSRV).
If you think this result is erroneous, please run: `cargo check --all` manually.
If the above does succeed, or you think cargo-msrv errored in another way, please feel free to
report the issue at: https://github.com/foresterre/cargo-msrv/issues
Thank you in advance!
The Reporter
was supposed to make everything effortlessly callable, and faster to compile, but did not have the hoped effect, as it makes it overly complicated to implement and access specific methods only for some Outputs (they now require either downcasting or an exposing trait implementation for all outputs).
We do something pretty dumb right now: simply take the minor versions and decrease it. But we do have all versions available, even ordered already, so instead we should be slightly smarter and first build and index of available versions, and then for each latests available minor version run the check.
I just tried the tool out and it doesn't work for me:
project-rs on ๎ main [?] is ๐ฆ v0.1.0 via ๐ฆ v1.51.0 took 12s
โฏ cargo msrv
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-apple-darwin
Using check command cargo build --all
Done red light for 1.51.0 โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ 00:00:01
Failed check command cargo build --all didn't succeed
Unable to find a Minimum Supported Rust Version (MSRV).
If you think this result is erroneous, please run: `cargo build --all` manually.
If the above does succeed, or you think cargo-msrv errored in another way, please feel free to
report the issue at: https://github.com/foresterre/cargo-msrv/issues
Thank you in advance!
Running cargo check
works and the exit code is 0.
rustc: rustc 1.51.0 (2fd73fabe 2021-03-23)
macOS: Big Sur 11.2.3 (20D91)
Currently, users see some rather slim amount of log output (only fetch, check, and the result).
Investigate:
Re-design of CLI interface
==========================
why?
* too many option stacked below the primary command
* certain flags and options are irrelevant for certain actions
* improve clarity
redesign based on current:
--------------------------
cargo msrv
--output human xor json
--no-logging
cargo msrv list
Lists the msrv's of all (transitive) dependencies, and computes the MSRV based on these values
--include-dev
--include-build
--no-transitive
--no-compute-msrv
cargo msrv verify
Tests a crate against a given msrv
.... file: Cargo.toml key: metadata.msrv
.... env: CARGO_MSRV_VERIFY
.... arg: --msrv {}
--on-error=(
exit,
msrv-run,
cargo-check,
)
--strategy (ast, toolchain, (db))
cargo msrv run (?)
Determine the MSRV for the given crate
--minimum or CARGO_MSRV_MINIMUM
--maximum or ...
--source SOURCE or ...
--no-edit-cargo-toml or ...
--beta xor --nightly
--strategy (ast, toolchain)
cargo msrv install
(no args) install [package.metadata.msrv] toolchain
cargo msrv pre-install-toolchain
(list of versions) these versions
(version range)
(expected bisection range)
(Pre) install toolchains for current platform if necessary
longer term:
------------
cargo msrv submit
Submit (vote) working versions to database
cargo msrv lookup
Attempts to look up the msrv of dependencies
Uses Cargo.toml metadata.msrv or/and database
As obtained sources by cargo
exported from notes
--minimum <version>
(default: Rust 1.31, first Rust edition 2018 version) and --maximum <version>
(default: latest version)--search-strategy <name>
(or just --strategy <name>
) commandOne of my projects is supported by Rust 1.30.0+, however cargo-msrv reports that the minimum version is 1.38.0.
If I manually run cargo check
or cargo test
with an earlier version:
$ cargo +1.37.0 check
error: failed to parse lock file at: /home/lucas/stringslice/Cargo.lock
Caused by:
invalid serialized PackageId for key `package.dependencies`
It looks like the format of Cargo.lock has changed slightly between 1.37.0 and 1.38.0. If I delete Cargo.lock and rerun cargo check
or cargo test
it passes:
$ rm Cargo.lock
$ cargo +1.37.0 check
Updating crates.io index
Finished dev [unoptimized + debuginfo] target(s) in 2.94s
However, if I try this with cargo msrv
it will first regenerate the Cargo.lock file with the latest stable Rust (currently 1.52.0), which then fails to parse when it gets to 1.37.0.
The only way I can get it to correctly report the correct MSRV is running with --maximum=1.37.0
so that it generates a Cargo.toml compatible with Rust<=1.37.0:
$ rm Cargo.lock
$ cargo msrv --maximum=1.37.0 --minimum=1.20.0 -- cargo test -- --test-threads=1
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo test -- --test-threads=1
Finished The MSRV is 1.30.1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ 00:00:28
The best solution I can think of is adding a --ignore-lock-file
flag to move/delete Cargo.lock and let Cargo regenerate it with each toolchain version. This means gives the user the option of whether to use or ignore the lock file.
--edition <value>
: reduces the search space to the Rust versions which provide support for a certain edition.
example:
--edition 2018
would include Rust versions >= 1.31.0
Older Cargo versions do not support newer lock files.
When running cargo-msrv against a project with a newer Cargo lock file, but with an older toolchain version, the cargo binary in this toolchain distribution does not support the newer lock file.
As a result, cargo-msrv fails to find the true MSRV.
It can be solved in a number of ways:
Let the latest Cargo version invoke an older toolchain, instead of the toolchain included in the same distribution.
Convert between the lock file versions (potentially lossy)
Accept unfrozen versions for dependencies and ignore the lock file (the --ignore-lockfile
option currently does this)
The currently WIP AST based analysis completely side steps this issue, but has the down (or up) side that tooling included in a Rust distribution is not taken into account. A question here is what the Rust in MSRV means (i.e. distribution, compiler or even spec if there was any). Regardless, if this analysis strategy will be added, the others won't be removed, so the problem will persist.
Currently (since #16), we'll always use the 'minimal' profile.
I am interested in publishing a (binary) package to AUR for this tool. To make this easier, it would be nice if (at least) a Linux build would be attached to each release.
Would you be open to adding a GitHub workflow that attaches a binary to each release? I am happy to submit a PR for that.
By ignoring the lockfile, it will be regenerated for each run. The idea behind it is that we can have some compatibility for different lock file versions. However, even with a lockfile, a dependency version may be updated to a (hopefully semver compatible) version which falls within the semver requirements. If some dependency then introduces a change which breaks our MSRV, while Cargo pulls in a specified, newer, matching semantic version, we may still fail.
As an example: if we have an dependency A, with published versions 0.1 and 0.2, and our in-repo lockfile takes 0.1 while a newly generated lockfile may take 0.2 instead, and 0.2 has a higher MSRV than 0.1, then by removing the lockfile we our MSRV changes, which is a problem for MSRV verification.
Example failure run: https://github.com/foresterre/cargo-msrv/runs/3809534104#step:8:1
In this specific case, on Rust toolchain versions below 1.46 (our MSRV is 1.42), we get the following error:
error[E0658]: `while` is not allowed in a `const fn`
--> /user/.cargo/registry/src/github.com-1ecc6299db9ec823/http-0.2.5/src/header/value.rs:85:9
|
85 | / while i < bytes.len() {
86 | | if !is_visible_ascii(bytes[i]) {
87 | | ([] as [u8; 0])[0]; // Invalid header value
88 | | }
89 | | i += 1;
90 | | }
| |_________^
|
= note: for more information, see https://github.com/rust-lang/rust/issues/52000
For the --ignore-lockfile
option itself, we'll need to figure out a strategy where we can convert between lockfile version, while keeping the versions in the Cargo.lock file the same. While in an ideal world, this error could have been prevented proper semver specifications, in the real world, such issues happen, and cargo-msrv should not overly rely on down-tree dependency specifications.
We currently read the Cargo.toml manifest in both the config.rs, and separately in manifest.rs.
We should de-duplicate this behaviour.
Ideas:
LazyManifestReader
, e.g. to the config, which handles reading the file lazilypackage.edition
field to manifest.rs
.To make the file reading lazy, we can use the OnceCell
data structure from https://crates.io/crates/once_cell.
Dedup:
https://github.com/foresterre/cargo-msrv/blob/main/src/config.rs#L297-L311
https://github.com/foresterre/cargo-msrv/blob/main/src/manifest.rs#L21
cargo publish --dry-run
:
warning: manifest has no documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
Available sources: https://docs.rs/rust-releases/0.16.0/rust_releases/#implemented-sources
stable
, if installed as suchrustup
doesn't install that version with an exact version specifier, we can have two copies of the same toolchain; For example if the latest stable is 1.51.0
, we get:
stable
toolchain (which was already installed)1.51.0
toolchain (installed by cargo-msrv)Since toolchain installation takes up significant time, it would be a good idea to reduce the installing of latest stable toolchain, even by one item; assuming it's available on the users system.
Currently we don't support beta and nightly versions, pending the upcoming rust-releases
update.
When running against the current cargo-msrv
it will produce an error like: could not find a satisfying MSRV for project
We should improve this error message, for the time being, until beta and nightly are supported
Improve error message
Example of current output:
Minimum Supported Rust Version (MSRV). If you think this result is erroneous, please run: `cargo check --all` manually. If the above does succeed, or you think cargo-msrv errored in another way, please feel free to report the issue at: https://github.com/foresterre/cargo-msrv/issues Thank you in advance!
Split from #124 (comment)
A Cargo.toml
file can have it's edition specified.
For example, the edition of this project is specified here:
https://github.com/foresterre/cargo-msrv/blob/main/Cargo.toml#L7
[package]
edition = "2018"
If this edition is present (package.edition
TOML key), we can use its value as the minimum version, similar to the --min
option.
The Cargo.toml
file can be read like this: https://github.com/foresterre/cargo-msrv/blob/main/src/lib.rs#L70-L77.
--
We should also add a flag to disable this behaviour: something along the lines of --no-read-min-edition
.
For inspiration on how to add the argument: https://github.com/foresterre/cargo-msrv/pull/129/files#diff-b2812f19576dd53d0c35b107a322f58a00fce6977f4b5976e1961853982af3ccR137-R1411
--
The idea of this issue is similar to #104, except instead of taking --min
as argument, it should read the version from the Cargo.toml
.
https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
From 1.56.0
See rust-lang/rust#65262
Currently nightly only.
For example using tracing which adds scopes and can be used to structurally log: https://tracing.rs/tracing/
Why?
We currently fetch the channel manifest only once on the first run, unless the cached file is removed.
This behaviour is unwanted as we need to deal with changes (every new Rust minor version update). Thus we need to add the ability to download a new copy of the channel manifest.
One possibility is to use the directories
crate (which is already included as dependency) and store a last checked on date in a file. Then we can take a delta time and if it is larger than some fixed duration (e.g. 1 day), we re-fetch the channel manifest and update the last checked date.
https://github.com/foresterre/cargo-msrv/blob/master/src/fetch.rs#L172
The issue comes because rust-releases
parses the Rust RELEASES.md
without looking at the release date if it is in the future or not.
The current RELEASES.md
starts like this,
Version 1.55.0 (2021-09-09)
============================
...
and rust-releases-rust-changelog/src/lib.rs#L42-L49
has this,
let releases = content
.lines()
.filter(|s| s.starts_with("Version"))
.filter_map(|s| {
s.split_ascii_whitespace()
.nth(1)
.and_then(|s| semver::Version::parse(s).map(Release::new_stable).ok())
});
PS. A workaround is to add --max 1.54.0
until 1.55.0
releases.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.