Makefile: add --locked #312

abdul124 · 2024-08-07T14:12:52+08:00

abdul124 commented

2024-08-07 14:12:52 +08:00

Freeze Cargo.lock and use same version of dependencies for each build.

Freeze `Cargo.lock` and use same version of dependencies for each build.

👍 2

abdul124 added 1 commit 2024-08-07 14:12:52 +08:00

Makefile: add --locked 7e52d06b41

sb10q commented

2024-08-07 16:03:34 +08:00

I have not seen any problem of cargo build changing the lockfile. How do you trigger it?

abdul124 commented

2024-08-08 09:47:51 +08:00

I have not seen any problem of cargo build changing the lockfile. How do you trigger it?

Running make command to directly build the target instead of using nix build updates the Cargo.lock file. Also, after further testing, cargo xbuild tends to ignore the --locked or --frozen flag. It updates the lock file first before passing these flags over to cargo. Is there any particular reason for using cargo xbuild over other alternatives like build-std flag from cargo?

> I have not seen any problem of cargo build changing the lockfile. How do you trigger it? Running `make` command to directly build the target instead of using `nix build` updates the `Cargo.lock` file. Also, after further testing, `cargo xbuild` tends to ignore the `--locked` or `--frozen` flag. It updates the lock file first before passing these flags over to cargo. Is there any particular reason for using `cargo xbuild` over other alternatives like `build-std` flag from cargo?

sb10q commented

2024-08-08 09:48:33 +08:00

Running make command to directly build the target instead of using nix build updates the Cargo.lock file.

Only in special circumstances where this is actually desirable (e.g. you added a dependency to Cargo.toml), no?

> Running make command to directly build the target instead of using nix build updates the Cargo.lock file. Only in special circumstances where this is actually desirable (e.g. you added a dependency to Cargo.toml), no?

abdul124 commented

2024-08-08 09:55:12 +08:00

Only in special circumstances where this is actually desirable (e.g. you added a dependency to Cargo.toml), no?

These are the changes it did:

It updated the path for git dependency (adding .git in the end)
Added any missing dependencies (tried removing some and it fetched their latest version from crates.io)
Restructure file, so all crates are in alphabetical order
Lastly, if any new dependency is added to Cargo.toml it will update the lock file

> Only in special circumstances where this is actually desirable (e.g. you added a dependency to Cargo.toml), no? These are the changes it did: 1. It updated the path for git dependency (adding .git in the end) 2. Added any missing dependencies (tried removing some and it fetched their latest version from crates.io) 3. Restructure file, so all crates are in alphabetical order 4. Lastly, if any new dependency is added to Cargo.toml it will update the lock file

sb10q commented

2024-08-08 09:56:01 +08:00

Sounds like you'd want these changes anyway?

sb10q commented

2024-08-08 09:56:32 +08:00

With missing dependencies the build would not work.

abdul124 commented

2024-08-08 10:05:13 +08:00

Sounds like you'd want these changes anyway?

It tends to add latest version of dependencies from crates.io in case of missing dependencies which are incompatible with the rust version we are using. For instance, it adds num-traits 0.2.19 which requires rust 1.62.0 to run and hence build fails. However, since the build will fail regardless (because of missing dependencies), I guess its mostly about what error message it throws. Also, for reproducibility wouldn't it be better to have the lock file locked unless we manually try to update it via cargo update?

> Sounds like you'd want these changes anyway? It tends to add latest version of dependencies from `crates.io` in case of missing dependencies which are incompatible with the rust version we are using. For instance, it adds `num-traits` 0.2.19 which requires rust 1.62.0 to run and hence build fails. However, since the build will fail regardless (because of missing dependencies), I guess its mostly about what error message it throws. Also, for reproducibility wouldn't it be better to have the lock file locked unless we manually try to update it via cargo update?

sb10q commented

2024-08-08 10:06:53 +08:00

That's just one of many issues with rust/cargo and trying to enforce the systematic use of --locked (or even --offline) is not really solving the problem.

sb10q closed this pull request

2024-08-08 10:06:53 +08:00