Install 0.19.3 fails about xh HOT 12 CLOSED

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.

from xh.

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.

from xh.

I can confirm this trying to install xh from crates.io.
Also on Linux with the latest stable Rust version.

from xh.

@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?

from xh.

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.

from xh.

It would likely be useful to add resolver = "2" to Cargo.toml to use the stricter dependency resolver.

from xh.

Hm, seems that it wouldn't have caught this problem but that sounds like a good idea.

from xh.

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.

from xh.

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.

from xh.

The fix has been merged, but there isn't a release yet. My workflows using xh are failing.

from xh.

Thanks. v0.19.4 has been released with just this one fix.

from xh.

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.

from xh.