Create a tool to manage version requirements in manifest and lock files
- Dominant language
- Rust
- Stars
- 188
- Forks
- 41
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 12
Description
We want the following properties:
- [ ] Lock files match manifest files. If a direct dependency version requirement is M.m.p, then the lock file should use M.m.p. This means that if some crate in the dependency tree has a stronger requirement, then the manifest must be updated to reflect that.
- [ ] Lock files should use the minimal version of indirect dependencies. The goal is to test that all possible dependency version resolutions compile. (Note that this assumes semver. If a dependency breaks semver, it should ideally be fixed and yanked, restoring semver at crates.io level.)
- [ ] When upgrading all dependencies, only direct dependencies for which a new major version has been published must be updated. The chosen version requirement should be minimal. This is partially (we don't use the minimal version) done by `cargo update --breaking` in `scripts/upgrade.sh`.
- [ ] We rely on dependabot and cargo audit to figure out if a version is vulnerable and should be bumped (usually patch version).
- [ ] Direct dependency versions may also be bumped if a specific feature of a minor version is needed.
- [ ] For crates that build on stable and the guarantee that they build on stable, we should provide `package.rust-version` and somehow check it (probably run test.sh with the MSRV too)
See https://github.com/rust-lang/cargo/issues/14372 for more information.
Useful tools: `cargo`, `cargo-lock`, `cargo_metadata`, `semver`, `tame-index`, and `toml_edit`.
Design ideas:
- Some `repo.lock` file at the root with a list of packages (name and version), one per compatibility range (see next point). This is the source of truth (`Cargo.toml` and `Cargo.lock` files must comply).
- Use some `struct CompatibilityRange { name: String, first: Version }` with an `fn first(&Version) -> Version` to easily talk about compatibility range. We want at most one version per compatibility range in the `repo.lock`.
- The version requirements in the `Cargo.toml` files must use the default and the version must be the one in `repo.lock`.
- The versions in the `Cargo.lock` must be the ones in `repo.lock`.
- We want to upgrade the `Cargo.toml` files if needed (using `toml_edit` in one go).
- We also want to fix the `Cargo.lock` files if needed (can we do it with the `cargo` library? or do we need to call the `cargo update` tool?). There is a difficulty if using `cargo update` that we want to start from the "roots", otherwise we might want to apply an update that doesn't work.
- The `repo.lock` should auto-update if a new compatibility range is needed.
(I have some code already.)
Contributor guide
Assessment
This issue has not been assessed yet.