Repository navigation
Version 0.600 disallows per module configuration globs like mypy-project.apps.*.migrations.* #5014
Description
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
Activity
emmatyping commentedon May 8, 2018
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.
[-]Bug: Version 0.600 disallows per module configuration globs like mypy-project.apps.*.migrations.*[/-][+]Version 0.600 disallows per module configuration globs like mypy-project.apps.*.migrations.*[/+]gvanrossum commentedon May 8, 2018
emmatyping commentedon May 8, 2018
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 commentedon May 8, 2018
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 commentedon May 24, 2018
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 commentedon May 24, 2018
@msullivan It looks like we really need to fix this.
msullivan commentedon May 24, 2018
Approximately how many packages do you have that those match, @nevc?
ncvc commentedon May 24, 2018
@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 commentedon May 25, 2018
I'll have a fix up soon to get it into 0.610
Allow wildcards inside of configuration section names
Allow wildcards inside of configuration section names
Allow wildcards inside of configuration section names (#5120)
Allow wildcards inside of configuration section names (#5120)