Version 0.600 disallows per module configuration globs like mypy-project.apps.*.migrations.*

[pwilczynskiclearcode]

I have a Django project with many apps and I want to disable mypy in all of migrations modules of each app. Up to 0.590 it was possible and since 0.600 this feature seems to be dropped.

This is my mypy.ini config:

[mypy-project.apps.*.migrations.*]
ignore_errors=True

[emmatyping]

The semantics of the config file changed in #4894 (which made it into the 0.600 release). It may be possible to relax the rules to allow wildcards within a pattern, but @msullivan would know more. Edit: I don't think this is a bug per se, so I'm labeling it a question for now.

[gvanrossum]

Hm, I'm wondering if we should roll back this limitation somehow. It's an edge case but it seems there are some real-world patterns that benefit. Unfortunately the only workaround in 0.600 is to list all modules separately (you can use [mypy-foo.migrations,bar.migrations,baz.migrations]).

[emmatyping]

Hm, I'm wondering if we should roll back this limitation somehow. It's an edge case but it seems there are some real-world patterns that benefit.

It can be relaxed, as glob can handle a wildcard in the middle of a pattern. Currently there is a check:
'*' in glob and (not glob.endswith('.*') or '*' in glob[:-2]), which prohibits the pattern given. I don't see why this limitation is needed.

[gvanrossum]

IIUC @msullivan discovered that a mypy.ini with many entries caused a big slowdown (due to something O(N**2) I'm sure) and fixed it using better caching in #4894, but the cache only supports * in the final component, or something.

[ncvc]

I think this will be a problem for many projects, Django especially. In our Django project, we currently ignore all errors in admin files since admin action attributes cause errors (project.*.admin), as well as all migration files since they're typically auto-generated (project.*.migrations.*). We also allow untyped function defs in test files since all our test functions don't return anything, so the annotations aren't useful (project.*.tests.*).

Would love to see support for these types of use-cases!

[gvanrossum]

@msullivan It looks like we really need to fix this.

[msullivan]

Approximately how many packages do you have that those match, @nevc?

[ncvc]

@msullivan We currently have 22 Django apps and are adding more pretty quickly, call it ~1 per month currently - both for feature work and splitting some of our existing bloated apps. We could add each app to our setup.cfg, but it makes adding apps more tedious and would reduce readability of the config.

[msullivan]

I'll have a fix up soon to get it into 0.610