The current (soon to be deprecated) vscode mypy linting behavior effectively allows mypy exclude-pattern consideration without depending upon linter-level ignorePatterns.
The resolution to #157 (using the experimental workspace scope) does not replicate the current vscode mypy functionality because it implicitly tethers the mypy ignore patterns to linter-level ignorePatterns which are often divergent. (e.g. one cannot allow ruff to lint 'setup.py' while still allowing a mypy exclude configuration to apply to 'setup.py').
The current functionality is enabled by passing an empty --exclude to python.linting.mypyArgs (i.e. "python.linting.mypyArgs": ["--exclude"]), which effectively suppresses the file-specific overrides of mypy exclude patterns (the behavior described in #157 (comment)) and results in linting at a repo-configured level. This allows linting a superset of the files over which mypy operates.
The current functionality is admittedly a bit of a hack so perhaps this issue is better cast as a feature request. Either way, perhaps porting the current behavior to dmypy by providing the user the ability to add args (such as --exclude) immediately prior to a given file or workspace (depending upon the dmypy reporting scope) would be acceptable? Essentially, I'm asking to reorder the current mypy-type-checker.args to provide them last and in so doing provide the user more control/flexibility to implement workarounds like this. I've verified (in both file and workspace scope) this approach would allow users to replicate the current functionality with dmypy while also avoiding the explicit endorsement of the aforementioned hack 😄
python -m mypy.dmypy run -- --show-absolute-path --show-column-numbers --show-error-codes --no-pretty --show-error-end --exclude /home/user/repo/reponame/setup.py
Success: no issues found in 10 source files
python -m mypy.dmypy run -- --show-absolute-path --show-column-numbers --show-error-codes --no-pretty --show-error-end --exclude /home/user/repo/reponame
Success: no issues found in 10 source files
Thanks for all your work on this valuable extension!
The current (soon to be deprecated)
vscodemypylinting behavior effectively allowsmypyexclude-pattern consideration without depending upon linter-levelignorePatterns.The resolution to #157 (using the experimental workspace scope) does not replicate the current vscode mypy functionality because it implicitly tethers the
mypyignore patterns to linter-levelignorePatternswhich are often divergent. (e.g. one cannot allow ruff to lint 'setup.py' while still allowing amypyexclude configuration to apply to 'setup.py').The current functionality is enabled by passing an empty
--excludetopython.linting.mypyArgs(i.e."python.linting.mypyArgs": ["--exclude"]), which effectively suppresses the file-specific overrides of mypyexcludepatterns (the behavior described in #157 (comment)) and results in linting at a repo-configured level. This allows linting a superset of the files over whichmypyoperates.The current functionality is admittedly a bit of a hack so perhaps this issue is better cast as a feature request. Either way, perhaps porting the current behavior to
dmypyby providing the user the ability to add args (such as--exclude) immediately prior to a given file or workspace (depending upon the dmypy reporting scope) would be acceptable? Essentially, I'm asking to reorder the currentmypy-type-checker.argsto provide them last and in so doing provide the user more control/flexibility to implement workarounds like this. I've verified (in both file and workspace scope) this approach would allow users to replicate the current functionality with dmypy while also avoiding the explicit endorsement of the aforementioned hack 😄Thanks for all your work on this valuable extension!