-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix all mypy issues #3979
Fix all mypy issues #3979
Conversation
(closed accidentally) |
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.
Thanks for the contrib! I've got some serious concerns about the checks for vendored modules, and some other suggestions about the approach, but for the most part it looks good.
* Use `pyproject.toml` instead of `mypy.ini` to merge tooling configurations (it also makes [exclude](https://mypy.readthedocs.io/en/stable/config_file.html#confval-exclude) configuration a bit cleaner as it supports arrays in `.toml` format) * If you still prefer having a standalone `mypy.ini`, I'll move it back and adapt the `exclude` config.
I do wish to retain the mypy settings in mypy.ini
for two reasons:
- The skeleton for this project is maintained upstream, which defines the mypy settings in its own file. Moving the settings to a different file makes it difficult to compare and manage the differences with settings inherited from upstream.
- Piling all project settings in pyproject.toml is a bad idea in general. I've been meaning to write a blog post about it, but the tl;dr is that because there's no ordering or namespacing, the settings lack structure and consistency (compared with
mypy
which always appears afterdocs/
and beforenewsfragments/
and is clearly distinct from towncrier or tox or pytest settings.
…tools into fix-all-mypy-issues
None
in _XfailMarkDecorator
's condition
param and expose default value
pytest-dev/pytest#11565
Co-authored-by: Anderson Bravalheri <[email protected]>
Update setuptools/tests/integration/test_pip_install_sdist.py Co-authored-by: Anderson Bravalheri <[email protected]>
…tools into fix-all-mypy-issues
Btw, with over 40 commits and lots of "oops" commits. Is this gonna be squashed merged? Or should I squash my git history? |
If you are more comfortable that way, I think you can do is a FYI, I recently merged a bugfix contributed by a member of that community that was having problems with building. That affects primarily |
I'm comfortable and experienced with interactive rebases, but for this PR you can just squash as a whole. With typeshed I've taken the habit of not force-pushing between reviews, as it is the policy there, since GitHub makes it harder to view changes since last review if the history is force-pushed, since it's based on commit history (unlike DevOps for example, where update history is separate from commits) |
Thank you very much @Avasam! That was a heroic piece of work. I have a doubt: How are you running $ mypy --python-version=3.8 --platform=linux .
setuptools/command/build_clib.py:6: error: Cannot find implementation or library stub for module named "distutils._modified" [import-not-found]
setuptools/command/build_clib.py:6: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
setuptools/config/_validate_pyproject/formats.py:180: error: Cannot find implementation or library stub for module named "trove_classifiers" [import-not-found]
setuptools/command/build_ext.py:19: error: Cannot find implementation or library stub for module named "Cython.Distutils.build_ext" [import-not-found]
Found 3 errors in 3 files (checked 146 source files) I can see that at least Is this something that is supposed to happen? |
@abravalheri Thank you too for your support! The last two ( Since I figured out how to enable mypy in CI, I have a very small follow-up PR that does just that an appropriately ignores "missing-imports" that happens on CI with a comment. #4257 |
Summary of changes
Progress towards #2345
I'm not familiar with tox or this project's CI setup, could I get a hand to ensure that mypy errors are blocking on the CI now that they're all fixed with base configuration?
Changes:
mypy.ini
to fit the current state of type-checking in this project:mypy . --python-version=3.8|3.11 --platform=linux|win32
results:A handful of separate PRs have been created and split from this one following review discussion:
importlib_machinery
code #4097AbstractSandbox._mk_*
methods #4099 or Call__func__
forAbstractSandbox
'sstaticmethod
s #4227self
argument #4144.gitignore
#4232posixpath.commonpath
supportsIterable
parameter python/typeshed#11310shlex.split
: allowTextIO
and deprecateNone
python/typeshed#11451sysconfig.get_config_var(s)
python/typeshed#11454None
in_XfailMarkDecorator
'scondition
param and expose default value pytest-dev/pytest#11565False
, instead ofNone
as default for_XfailMarkDecorator
'scondition
param and update doc pytest-dev/pytest#11600Pull Request Checklist
newsfragments/
. (should not affect the end user yet)(See documentation for details)