crates.io-index VS cargo-msrv

That's already prevented by the checksum which is present for all crate versions in the registry index, which is set in stone on publish and verified by cargo on download. See e.g. https://github.com/rust-lang/crates.io-index/blob/74f1b1e064...

Why is the crates.io registry Git repository structured the way it is? https://github.com/rust-lang/crates.io-index

# $HOME/.cargo/config.toml [...] [registry] default = "gitea" [registries.crates] index = "https://github.com/rust-lang/crates.io-index.git" [registries.gitea] index = "https://gitea.localhost.local/user/_cargo-index.get" [...]

[[package]] name = "cbindgen" version = "0.24.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "a6358dedf60f4d9b8db43ad187391afe959746101346fe51bb978126bec61dfb" dependencies = [ "clap 3.2.23", "heck", "indexmap", "log", "proc-macro2", "quote", "serde", "serde_json", "syn 1.0.109", "tempfile", "toml 0.5.11", ]

$ cargo upgrade --dry-run --compatible ignore --incompatible allow --pinned ignore --verbose 2>&1 Updating 'https://github.com/rust-lang/crates.io-index' index Checking foo's dependencies name old req compatible latest new req note ==== ======= ========== ====== ======= ==== axum 0.6.11 0.6.15 0.6.15 0.6.11 compatible base64 0.20.0 0.20.0 0.21.0 0.21.0 ...

I am getting: spurious network error (2 tries remaining): unexpected http status code: 503; class=Http Caused by: failed to fetch https://github.com/rust-lang/crates.io-index

https://github.com/rust-lang/crates.io-index contains the entire crates.io index with the names of all crates and their dependencies. grep or ripgrep over that should do the job.

[[package]] name = "spade" version = "2.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1190e0e8f4eb17fc3dbb2d20e1142676e56aaac3daede39f64a3302d687b80f3" dependencies = [ "num-traits", "optional", "robust 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", "smallvec", ]

Caused by: process didn't exit successfully: git fetch --force --update-head-ok 'https://github.com/rust-lang/crates.io-index' '+HEAD:refs/remotes/origin/HEAD' (exit status: 128) --- stderr error: 2747 bytes of body are still expected fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output

What this tool say? https://github.com/foresterre/cargo-msrv

I'm working on cargo-marv.

Before getting overcome by despair, have a look at cargo-msrv -- this little gem of a tool figures it all out for you!

I'll be adding a 'minimal' output format to cargo-msrv for use in scripts. I'll also be updating the book, and inch closer towards releasing v0.16.

First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815...

Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler?

Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected.

You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV).

You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo.

I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch.

Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.

Looks helpful though it doesn't seem to address when you don't have a Cargo.lock. I've created an issue for this.

I'll be switching over the CLI of cargo-msrv, from Clap's builder methods to the attribute macro. I hope this will simplify the configuration, as my Config and ConfigBuilder structs (which were build from Clap's ArgMatches) was growing fast, and becoming slightly unorganized. With the attribute macro, the config will be constructed directly by code generated by the macro. The mostly saves one intermediate step, and a lot of boilerplate.

Some combination of cargo-outdated and cargo-msrv could probably do this in a slightly more manual fashion.