Cargo.lock (and dependabot)

[DanielVoogsgerd]

Right now make.py does not use the argument cargo flag --locked. Perhaps it would be a good idea to use the versions provided in the lock file. This way, we know that people are actually compiling the same thing as we are. The downside of this would be that we would have to update the lockfile more frequently for people to use recent versions. I think it could help to use dependabot for it.

We can set it up that it would group together all backwards compatible updates so we only have to test the collection of updates during a entire month.

Major versions would require more attention and could be split into separate PRs by dependabot.

@Lut99 what do you think?

Should we compile with locked? Edit: Yes

• Add --locked to make.py

Should we use dependabot to update lockfile versions? Edit: Yes

• chore(deps): Add dependabot #101

[Lut99]

Lmao. Here I was thinking that using the lockfile is default behaviour... But what does it do if not that? Isn't all that cargo update does update the file versions in the lockfile to highest allowed by the bounds in Cargo.toml?

Either way ~ yes I want to fix the versions people use (by default). So using --locked sounds very good to me.

I'd be more hesitant to automatically updating lockfile versions, especially in case of "hibernation" of the project. I'd rather go in every so often and do some updating myself, just to be sure that what's there will work.

[DanielVoogsgerd]

Yeah I could have explained this a bit better. This is my (hopefully correct) current understanding of Cargo.lock is as follows: Cargo.lock is updated if Cargo.toml is newer than Cargo.lock or if one calls cargo update. --locked refuses to do the first one and fails instead, this sounds harsh, but the advantage is that we know that dependencies were not updated unless done explicitly by an installing user.

I already added --locked as a check to the build in CI too, hopefully this will ensure we don't merge Cargo.toml updates without updating the lockfile as well which will prevent most issues already.

With respect to dependabot, we can set it up in a way where it would merge itself, but we can also set it up where it creates PRs when updates are available. It can also group together all semver compatible updates in a single PR lets say once a month (an interval I have settled for personally, ymmv). Major updates I are more complicated as frequently more work is involved unfortunately, but we could still set that up so that it would create a PR for those, but probably just one by one.

Here an example of a very attention deprived personal project of mine where I use dependabot in such a way: DanielVoogsgerd/waybar-extensions-rs#84

[Lut99]

Ahh, I see. That matches my expectation of how it worked as well :) but I agree then that --locked is better.

I also like the way of using dependabot to create PRs. That would do the thing I meant to do but like, automagically :)

+1!