mypy.ini is missing

[jolaf]

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.

[srittau]

This seems like a good idea to me. What do the other maintainers think?

[jolaf]

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]

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 regular pytype tool is, but adding a mypy config file sounds perfectly reasonable to me.

[Avasam]

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]

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.ini file.

I'm guessing the experience when editing typeshed locally in an IDE could still be improved. But I feel like adding a mypy.ini file 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 a mypy.ini file (or a config section to pyproject.toml), that might lead people to erroneously think that all they need to do to run mypy on typeshed is to do mypy . -- and for typeshed, there's no way to make that work. If somehow they find a way to make mypy . 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 :/