Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
6 tasks
ia0 opened this issue Aug 9, 2024 · 0 comments
Open
6 tasks
Labels
crate:xtask Modifies the maintainers CLI for:maintainability Improves maintainers life for:security Improves firmware or project security for:usability Improves users (and maintainers) life needs:design Needs design to make progress

Comments

@ia0
Copy link
Member

ia0 commented Aug 9, 2024

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 rust-lang/cargo#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.)

@ia0 ia0 added needs:implementation Needs implementation to complete crate:xtask Modifies the maintainers CLI for:security Improves firmware or project security for:usability Improves users (and maintainers) life for:maintainability Improves maintainers life labels Aug 9, 2024
@ia0 ia0 added needs:design Needs design to make progress and removed needs:implementation Needs implementation to complete labels Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate:xtask Modifies the maintainers CLI for:maintainability Improves maintainers life for:security Improves firmware or project security for:usability Improves users (and maintainers) life needs:design Needs design to make progress
Projects
None yet
Development

No branches or pull requests

1 participant