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 mypy configuration file that ignores existing errors on a per-file and per-error basis #2424
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2424 +/- ##
==========================================
- Coverage 96.92% 96.91% -0.01%
==========================================
Files 104 104
Lines 9127 9122 -5
==========================================
- Hits 8846 8841 -5
Misses 281 281 ☔ View full report in Codecov by Sentry. |
Setting up the mypy configuration in pyproject.toml was giving me a headache when I was trying out how to exclude files.
I just got mypy to pass for the first time in continuous integration ever on PlasmaPy, and all I needed to do was set it to completely ignore 79 files. 🥲 Oh well...it's a starting point! |
The number of files that aren't passing mypy went down after #2421, as expected! |
pyproject.toml
Outdated
"pandas-stubs >= 1.5.0.221010", | ||
"pre-commit >= 3.0.0", | ||
"pytest-regressions >= 2.3.1", | ||
"pytest-xdist >= 3.0.2", | ||
"tomli >= 2.0.1", | ||
"tox >= 4.3.1", | ||
"types-requests >= 2.27.1", | ||
"types-tqdm >= 4.66.0.3", |
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.
For packages that don't include type hints themselves, there sometimes exists stub packages that contain typing information. We might want to separate these out later on so that they don't get installed every time we run tests.
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.
Is it worth adding a line comment on these packages explaining what they are (type information for the associated package)?
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.
Good idea!
Strangely, I was getting different results from mypy using a pre-commit hook vs running it locally. I think it's probably due to running different versio of mypy.
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 - shouldn't really change much for users/developers until added to CI, except for the few new minor added requirements.
One note - presumably between now and when CI is turned on, more changes will be made to the code and it's possible the list of exception files will change and need to be updated in the PR that turns on CI?
# We can get to passing mypy's strict mode by incrementally changing the | ||
# following global settings to true. This comes from mypy's documentation. | ||
|
||
warn_unused_configs = true |
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.
Right now they are all true
- you mean you'd change all/some of these to false
prior to adding this to CI?
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.
Good catch! I was debating back and forth about this. If we keep all of these true, then we can ensure that new files will be consistent with mypy's strict configuration. Adding type hint annotations is much easier while writing code, so I'm thinking we should try out strict mode. If any of the settings cause any headaches, we can set them to be false.
In this case...I need to update the comment!
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.
I agree. On the other hand, if you want this in the package I'm in favor of getting it into CI as soon as possible to at least stem the flow of new files without type hints. Maybe we can change some of these to false when adding this to CI to ease into it.
@pheuer — thank you for the review! This is by no means the final version of the mypy configuration. We'll need to play around with it to see what it's like.
True! I'm hoping to submit a PR to add mypy to CI soon, but we'll need to add some content to the contributor guide along with it.
Yes, this is unfortunately true too. I'm planning to regenerate the configuration file unless I get it added to CI sooner rather than later. My biggest worry about this approach is that it'll be hard to maintain manually. But...this configuration is only a starting point. Thank you again for the review — I appreciate it! |
stopping_power: u.Quantity[u.J / u.m, u.J * u.m**2 / u.kg], | ||
mass_density: Optional[u.Quantity[u.kg / u.m**3]] = None, |
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.
I missed these in #2421.
Description
The PR adds an initial mypy configuration file,
mypy.ini
. To get it to pass, I set it toignore a whole bunch of filesignore specific error codes in a bunch of files.Motivation and context
We currently have no method for checking that our type hint annotations are accurate. Enabling the
mypy
static type checker will fill this gap in our continuous integration testing.Prior to #2421 and this PR, running
mypy plasmapy
led to 719 errors, of which ∼200 are from untyped packages like Astropy and SciPy. Rather than fixing all of these errors at once, I wanted to add a configuration formypy
that passes, even if it means that we ignore errors in a whole bunch of files. After merging this, we can gradually go through PlasmaPy file-by-file and error code by error code to getmypy
to pass in strict mode. For errors that are difficult to deal with we could add# type: ignore[specific-error-code]
comments so that the rest of the file gets type checked.Related issues
Closes #268. Depends on #2421.