Closed jayvdb closed 8 months ago
I can confirm this trying to install xh
from crates.io.
Also on Linux with the latest stable Rust version.
Ouch! I'm guessing we depend on a crate that used to enable the feature and now doesn't.
Maybe cargo update
should be part of the release checklist.
@blyxxyz I wasn't aware but it looks like cargo-install respects any present Cargo.lock
file when the --locked
option is used. Do you see any downsides in recommending that instead?
It means people will miss out on bug fixes, and not everybody is going to notice it. But I've seen packages that recommend it. Some of the distro packages already build with --locked
.
It's good practice either way to regularly run cargo update
and watch out for vulnerabilities. But with --locked
it would be even more important.
I don't have a strong opinion for or against.
It would likely be useful to add resolver = "2"
to Cargo.toml to use the stricter dependency resolver.
Hm, seems that it wouldn't have caught this problem but that sounds like a good idea.
Just the view of a package maintainer here ...
Releases need to be built with --locked
or --offline
when it comes to packaging. This because, there are basically 3 phases of a package build; fetch, build and install.
At least on NetBSD, the fetch phase fetches the source files into the build directory. During the build phase, dowloads are not allowed, only what was already downloaded during fetch is supposed to be used. So, if extra source files are needed, the build will fail.
Not all packaging systems are that strict but, I think it's good that we do it this way. When we fetch source files, we also calculate checksums, so if a file has been altered the build will fail due to a checksum mismatch. This way, we can improve security by only using files that have a checksum assigned.
It would likely be useful to add resolver = "2" to Cargo.toml to use the stricter dependency resolver.
We're on edition 2021, so it should default to the newer resolver (I think)
By the way, how helpful do you find our MSRV policy? We could periodically run cargo update
but that means we would raise the minimum supported Rust version more often.
Also, I noticed that installing xh from crates.io without the --locked
flag requires at least 1.70 but our stated MSRV is 1.64.
Also, I noticed that installing xh from crates.io without the --locked flag requires at least 1.70 but our stated MSRV is 1.64.
As long as it states the actually required MSRV it's fine. Personally, I'm nearly always on the latest stable but, NetBSD itself is usually on latest -1.
Right now, I'm on 1.73 and NetBSD is on 1.71.1. So, I like when projects state MSRV, so I don't push things that build on my dev system but, fail on the build servers.
The fix has been merged, but there isn't a release yet. My workflows using xh are failing.
Thanks. v0.19.4 has been released with just this one fix.
I have now added cargo update
to our release checklist file.
We will also start updating dependencies more aggressively and encourage people to use the --locked
option when installing xh from crates.io.
Installing from crates.io and git (
rustup run stable cargo install --path .
) fails. I'm on Linux.