MAINT: update pip constraints and pre-commit

[redeboer]

Automated changes by create-pull-request GitHub action

This PR is preparation for #293, which requires upgrading the constraint files. We want to keep the diff on these constraint files small in the linear commit history of the main branch.

[mmikhasenko]

Hi @redeboer, just wonder why does one need to update the constraints?
Is it to the most recent?
Is it automatic?
What is a command that checks for updates? (conda up or something?)

[redeboer]

Hi @redeboer, just wonder why does one need to update the constraints?

Constraint files are a bit like Julia's Manifest.toml: they pin all indirect required packages, so that results from the application are reproducible for each commit. One may question whether a package that is intended as a library should have constraints, but that is why the direct dependencies are listed in setup.cfg with loose version ranges (as to cause as little problems downstream as possible).
For most ComPWA repositories, the constraint files are there mainly for CI, for instance making sure that the documentation is run and built consistently (the notebooks are kind of an application) and making it easier to figure out if checks fail due to changes in the dependencies.

Is it automatic?

The constraint files are upgraded automatically with ComPWA/update-pip-constraints, which wraps around pip-tools. It is triggered when a PR¹ changes files that affect dependencies, through a scheduled job with a certain frequency, or with a manual workflow dispatch:

Is it to the most recent?

Yes, pip-tools pins the dependencies to versions that are as high as allowed by the package dependency listing while trying to avoid dependency conflicts. Note that all extra [dev] dependencies are included in the constraint files, which potentially constrains the pinned versions to a narrower range (there are more potential dependency conflicts to resolve).

What is a command that checks for updates? (conda up or something?)

Locally there is no easy way to do this, especially if you want to pin the constraint files for each supported Python version (strictly speaking, the constraint files could differ for different versions of Python). See also ComPWA/update-pip-constraints#6. The command to produce each file is automatically embedded in the constraint file itself though.

Footnotes

1. Only PRs from a branch, because PRs from a fork do not have sufficient rights. See e.g. Clean caches for PR from a fork actions#9. ↩

[redeboer]

Btw, I triggered this PR manually to first upgrade the constraint files in a single commit and then add a constraint file for Python 3.11 in a follow-up commit through #293.