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

Add type casting to fix failing mypy lint #33

Merged
merged 2 commits into from
Oct 9, 2024
Merged

Add type casting to fix failing mypy lint #33

merged 2 commits into from
Oct 9, 2024

Conversation

samuelallan72
Copy link
Contributor

The mypy lints were failing since the release of ops 2.17.0. The problem does not appear to be with ops,
but rather with how type narrowing works with mypy, and how the charm assigns the unit status in different methods. See canonical/operator#1401 for more context.

We can fix the issue with no changes to the charm logic by adding type casting to undo the type narrowing in this case.

The mypy lints were failing since the release of ops 2.17.0.
The problem does not appear to be with ops,
but rather with how type narrowing works with mypy,
and how the charm assigns the unit status in different methods.
See canonical/operator#1401
for more context.

We can fix the issue with no changes to the charm logic
by adding type casting to undo the type narrowing in this case.
@samuelallan72
Copy link
Contributor Author

Note: ideally we would refactor the charm to avoid setting unit.status from many locations - instead hooking into the collect-status event and setting the unit status from one method. But this is a minimal change to unblock the CI, until we have time to refactor the code.

Copy link

@dimaqq dimaqq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drive-by 2c:

The proposed cast is [semantically] equivalent to # type: ignore.

I'd rather see a type ignore with a comment like Status collection across XXX needs to be refactored, a band-aid for now and an issue opened to eventually refactor.

@chanchiwai-ray
Copy link
Contributor

@dimaqq was mentioning about using type ignore instead, what do you think? For me, it makes more sense to ignore a typing error than hacking the code to make the type checker happy

@samuelallan72
Copy link
Contributor Author

The proposed cast is [semantically] equivalent to # type: ignore.

I'm not sure how this is equivalent? Wouldn't ignoring the type be more equivalent to casting it to Any? By type casting to StatusBase, we're asserting to the type checker that it's at least compatible with StatusBase, which should allow it to provide us more useful information than simply ignoring the type altogether.

@samuelallan72
Copy link
Contributor Author

Note, if we went the route of ignoring the type, we'd need the ignore comment on all the lines affected by the "unreachable" rule. Eg. the first one would look like this:

diff --git a/src/charm.py b/src/charm.py
index 029bda9..f594fa6 100755
--- a/src/charm.py
+++ b/src/charm.py
@@ -163,8 +163,8 @@ class StorageConnectorCharm(CharmBase):
             return
 
         self._check_mandatory_config()
-        if isinstance(self.unit.status, BlockedStatus):
-            return
+        if isinstance(self.unit.status, BlockedStatus):  # type: ignore
+            return  # type: ignore
 
         # install packages
         cache = apt.cache.Cache()

@samuelallan72 samuelallan72 merged commit 35ea26e into main Oct 9, 2024
3 checks passed
@samuelallan72 samuelallan72 deleted the fix-mypy branch October 9, 2024 08:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants