Please bring back the lock file!

[alerque]

dua-cli/.gitattributes

Line 1 in 2ef583d

/Cargo.lock export-ignore

This breaks distro packaging and reproducible builds. It's not the right solution, sorry. Just update the lock file to get fresh dependencies that work with Rust 1.80 and commit that. What happened with Rust 1.80 was an upstream snafu and not your fault, but this is quite unusual in the ecosystem and this breaks more things than it fixes.

A patch release with this dropped so people can just build out of the box again including cargo build --release --locked would be appreciated.

[emilazy]

(Just linking #253 (comment) for connectivity.)

[Byron]

It's fixed in main now, and a new release was made.

[emilazy]

Thank you for addressing this so quickly!

[polarathene]

This breaks distro packaging and reproducible builds. It's not the right solution, sorry.

Is this a common practice to rely on GH release archives? If you're building from source wouldn't you do a shallow clone of the repo for the given release tag instead? That would still have included the Cargo.lock?

Just curious. I see that the releases include a source archive too, so I guess I can see how that's a problem, just a tad surprised why that'd be preferred vs cloning the repo by tag 🤔

[alerque]

Yes it is quite common. Tarballs are much easier to verify (checksums are a single command on a single file away). You certainly can validate a clone, but the most robust way to do this is to use git archive to concatenate everything together and checksum that, so using the upstream archives are one step shorter. Also tarballs are easier to cache and pass around between build servers, etc. Again all things that can be overcome, but tarballs are typically less friction to accomplish the same thing.