google / google/wasefire

Create a tool to manage version requirements in manifest and lock files

Open
#583 0 comments 0 reactions 0 assignees View on GitHub
crate:xtask for:maintainability for:security for:usability needs:design
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.