fix(py): Type stubs for calibration types reflect breaking changes in 0.13.0 #421
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…t breaking changes in 0.13.0
|
Note: These failures don't necessarily block the PR but both authors and reviewers should check the results for unintentional breaking changes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The release of 0.13.0 changed the data model for calibration types, but the stubs did not reflect these changes.
Interestingly,
stubtestdid not catch this issue, but in downstream packagesmypyraised errors when trying to use calibrations in the updated way. To prevent going back forth between changes here and in pyQuil, I've added a CI step that checks if changes in PRs fail validation against pyQuil. This catches the problem that caused this issue, as well as any other change that makes a test or lint fail. Getting this job to pass is optional, since breaking changes are expected to cause issues downstream. I think, if we choose to expand this pattern, each repo should own and publish a testing workflow. That'll prevent the details of each package from leaking into different repos, and makes it so that it can be implemented once, and called by any other GitHub workflow.This PR is already blocking rigetti/pyquil#1809, so I'd like to get this merged, but I plan to port the workflow to pyQuil if we want to apply this approach to qcs-sdk-rust.