Add mypy type checking to CI (#226) - #2398
Conversation
Signed-off-by: AravCS <aravshah927@gmail.com>
Signed-off-by: AravCS <aravshah927@gmail.com> Co-authored-by: tristonfgibson <246780826+tristonfgibson@users.noreply.github.com> Co-authored-by: yaeger211202 <163278221+yaeger211202@users.noreply.github.com>
|
Hi @yaeger211202 and @tristonfgibson, I think it may be a good idea to use I think the best way to discuss this in more detail is to create an issue in https://github.com/aboutcode-org/skeleton/. If it proves useful, we can integrate it into all of our projects. |
|
Hi @ziadhany, thanks for the reply! As you suggested, I've opened an issue in skeleton: aboutcode-org/skeleton#106 |
| files = | ||
| # fetch and parse vulnerability data from upstream sources | ||
| vulnerabilities/importers/debian_oval.py, | ||
| vulnerabilities/importers/epss.py, | ||
| vulnerabilities/importers/project_kb_msr2019.py, | ||
| vulnerabilities/importers/redhat.py, | ||
| vulnerabilities/importers/suse_scores.py, | ||
| vulnerabilities/importers/ubuntu_usn.py, | ||
| vulnerabilities/importers/xen.py, |
There was a problem hiding this comment.
I think we should use an exclude list instead. Adding every file individually isn't a good option, especially because whenever we create a new file, it will require manually updating the mypy configuration.
| mypy: | ||
| @echo "-> Run mypy type checking" | ||
| @${ACTIVATE} mypy | ||
|
|
There was a problem hiding this comment.
I think mypy command should also be part of check command
| warn_unused_ignores = True | ||
|
|
||
| strict_equality = True | ||
| warn_return_any = True |
There was a problem hiding this comment.
There are a lot of options available. The main question is whether any of them work well with django without requiring a plugin.
3 participants
Hello me and my team, @yaeger211202 and @tristonfgibson worked on this as part of CodeDay Labs. Here is a summary of our changes:
Added mypy type checking to CI. Consists of already-clean, high-value modules as the initial whitelist target.
Rather than running mypy across the whole codebase (pre-existing errors), it uses a whitelist in mypy.ini, only the listed files are checked. This follows mypy’s existing-codebase docs by starting on a clean subset and expanding over time. Config uses mypy’s recommended foundation settings as well.
Changes pass both locally and on Github Actions (run on a fork against current main).
Changes: