Repository navigation
mypy.ini is missing #2852
Description
I have .mypy.ini file that I use for my projects, in my home directory, and it's pretty strict.
It took me some time to find out that all the typeshed test failures I see are due to the fact that mypy finds that config file and uses it to run tests.
Besides this confusion, that can lead to a more serious problem when someone has a relaxed .mypy.ini in one's home, and that could cause the tests to pass while in fact they should not.
Suggestion: having a correct mypy.ini inside the typeshed and configuring all the test scripts to use it explicitly.
Probably something similar should be done for pytype.cfg and .flake8.
Activity
srittau commentedon Mar 11, 2019
This seems like a good idea to me. What do the other maintainers think?
jolaf commentedon Mar 11, 2019
Unfortunately I couldn't create an operational fix for
mypy_selftest.py.Whatever I tried, the tests somehow manage to find and use
~/.mypy.ini.rchen152 commentedon Mar 13, 2019
A pytype.cfg isn't needed, since the typeshed test uses
pytype-single, which is a debugging/testing tool that isn't configurable like the regularpytypetool is, but adding a mypy config file sounds perfectly reasonable to me.Allow per distribution mypy strictness options (#5169)
Avasam commentedon Jan 16, 2023
mypy.ini(or equivalent) just by itself would be beneficial for editors for more accurate mypy configs. But it'd also mean duplicating the config in the test and there.AlexWaygood commentedon Jul 22, 2023
I think this is no longer needed for people to get our tests that use mypy to pass locally: command-line flags always override config files for mypy, and all of our scripts that invoke mypy (
mypy_test.py,regr_test.py,typecheck_typeshed.py) pass a fairly exhaustive array of command-line flags to mypy these days, so we should be overriding any config a user has in a local~/.mypy.inifile.I'm guessing the experience when editing typeshed locally in an IDE could still be improved. But I feel like adding a
mypy.inifile could possibly actually just cause confusion in that regard. Typeshed's a pretty unique project when it comes to the question of "how do I run mypy on typeshed?", and each bit of typeshed requires different mypy configs, which is why we pass different command-line flags in each script we have that invokes mypy. If we added amypy.inifile (or a config section topyproject.toml), that might lead people to erroneously think that all they need to do to run mypy on typeshed is to domypy .-- and for typeshed, there's no way to make that work. If somehow they find a way to makemypy .pass locally, they'll then be confused when they submit a PR and find CI failing.So, in summary: I don't think we should do this :/