Closed pavoljuhas closed 4 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 97.79%. Comparing base (
bfba965
) to head (65bfddf
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thank you @pavoljuhas for working on making Cirq Python 3.12 compatible. I see that some packages were bumped in order for tests to pass. Is there a policy for updating Cirq
dependencies? For example,
poetry update
.Thank you @pavoljuhas for working on making Cirq Python 3.12 compatible. I see that some packages were bumped in order for tests to pass. Is there a policy for updating
Cirq
dependencies? For example,
- I use poetry to manage my packages, which makes updating to the latest version feasible by the command
poetry update
.- Dependabot and Renovate do this too, as bot contributors to the repo ( i.e. they create their own PRs whenever an update is possible )
Thank you for your comment. In general we try to follow the NEP-29 version policy for Python and NumPy. As for other packages, we seek to use loose version specifications, e.g., somepackage~=1.2
to freeze the major version but match recent minor releases which in theory should have compatible APIs. Cirq is often used as a library that should be installable with other projects so we do not want to restrict its dependency specifications more than needed. If there is a breaking change for some third-party release, we add an upper bound for the last working version. These rules have a tendency to get outdated, which is a part of the process that could be improved.
We revisit dependencies at the release time or when there is a need for major-version upgrade of some package.
In regards to the poetry, the poetry update
creates a lock file with exact versions of all direct and transitive dependencies at the time of execution - which is useful for reproducible installations. The lock files are resolved from package version constrains in pyproject.toml which need manual updates so that part of labor seems to be the same.
It would be nice to get notifications when our requirement specs exclude the latest stable releases. We are glad to consider suggestions if you (or others) know of such tool.
Thank you for the thorough answer @pavoljuhas. My suggested approach would be either Dependabot or Renovate, as they generate small PRs which only update the relevant versions, making it easier to approve/reject version bumps. Usually it's nice to limit these to major versions, otherwise we get flooded with these PRs, and as maintainers there are more important things you can focus on :) I'd recommend:
Do you want me to create the issue?
engine_test.py::test_create_context
test_isolated_env_cloning
Fixes #6460