-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
fix: rework ops.main type hints to allow different flavours (callable class) #1345
Conversation
7268b54
to
1ee3242
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me - a few minor queries/suggestions.
I did not review any of the code in _main.py
other than main()
, assuming that it was unchanged from main.py
- if that's not the case and there are tweaks there too, could you please note that in the PR description and I'd want to re-review.
Speaking of the PR description: I assume it's because there are three competing solutions in different PRs, but it's currently empty: could you please fix that?
|
Can you just put in a custom inline target and link to that instead? You'd lose the auto formatting, but at least it would be a link. Like: def main(...):
"""_`ops.main()` is the thing you want to call."""
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of nit comments, comment about re-exporting those few names in main.py
, and question whether we need test_main_type_hint.py
.
Docs look good though -- thanks! |
I've decided to re-export the set of symbols that Scenario 6 uses specifically. Rationale: many charms use Scenario and we shouldn't potentially break a whole bunch of charms if they pin dependencies asymmetrically (compatible ops, exact scenario); and to decouple Scenario 6 update from this PR in calendar time. |
4a93b38
to
ede4507
Compare
I've given things a read through and it looks good to me, with the caveat that I'm still not familiar enough with the code base for that to signify a lot. I raised a couple of questions on test_main_type_hint.py just about the type checking tests. |
50df742
to
8c0290d
Compare
Jira: https://warthogs.atlassian.net/browse/CHARMTECH-223 Parent: https://warthogs.atlassian.net/browse/CHARMTECH-219 The idea is to validate that the charm initialises the operator framework correctly: - charmcraft analyse would validate the presence of the `ops.main(...)` call with this PR - any conceivable import style is supported - ops library type hints are improved canonical/operator#1345 - charmers will no longer need to slap `# type: ignore` on the call - we'll be relying on charmers' static type analysis to ensure correct arguments to `ops.main` --------- Co-authored-by: Alex Lowe <alex.lowe@canonical.com>
Merge readiness check
Release readiness check
lint
step gets broken chore: reenable ops.main type hints hardware-observer-operator#298Slated for ops==2.17.0
https://warthogs.atlassian.net/browse/CHARMTECH-232