[BUG] no way to specify some mypy args

[gmankab]

Describe the bug

Hello, here are some very important options in mypy linter, like --ignore-missing-imports and --no-site-packages, prospector understands first one, but doesn't understand second one.

To Reproduce

prospector_profile.yml:

mypy:
  run: true
  options:
    no-site-packages: true
    ignore-missing-imports: true

main.py:

import requests
import this_module_not_exits

prospector command:

python -m prospector --profile prospector_profile.yml main.py --output-format json

mypy command:

python -m mypy --no-site-packages --ignore-missing-imports main.py

running mypy command without args gives two errors:

$ python -m mypy main.py 

main.py:8: error: Library stubs not installed for "requests" (or incompatible with Python 3.10)
main.py:8: note: Hint: "python3 -m pip install types-requests"
main.py:8: note: (or run "mypy --install-types" to install all missing stub packages)
main.py:8: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
main.py:9: error: Cannot find implementation or library stub for module named "this_module_not_exits"
Found 2 errors in 1 file (checked 1 source file)

Adding first argument disables first error, and adding second argument disables second error.

But not with prospector.

If I commenting arguments for mypy in prospector_profile.yml:

mypy:
  run: true
#   options:
#     no-site-packages: true
#     ignore-missing-imports: true

Then I getting same two errors. But if I uncommenting it, only second error disappears, while first error Library stubs not installed for "requests" still here.

Expected behavior More universal way to specify arguments, for example:

mypy:
  run: true
  options:
    - --no-site-packages
    - --ignore-missing-imports

or:

mypy:
  command:
    - python -m mypy --no-site-packages --ignore-missing-imports

or:

mypy:
  profile_path:
    - mypy_profile.ini

Environment:

• OS: Windows 11 Home 21H2 22000.527
• Tool: mypy
• Prospector version: 1.7.6
• Python version: 3.10.2

Additional context

$ pip freeze

astroid==2.9.3
bandit==1.7.4
certifi==2021.10.8
charset-normalizer==2.0.12
colorama==0.4.4
docutils==0.18.1
dodgy==0.2.1
flake8==4.0.1
flake8-polyfill==1.0.2
frosted==1.4.1
gitdb==4.0.9
GitPython==3.1.27
idna==3.3
isort==5.10.1
lazy-object-proxy==1.7.1
mccabe==0.6.1
mypy==0.940
mypy-extensions==0.4.3
pbr==5.8.1
pep8-naming==0.10.0
pies==2.6.7
platformdirs==2.5.1
prospector==1.7.6
pycodestyle==2.8.0
pydocstyle==6.1.1
pyflakes==2.4.0
Pygments==2.11.2
pylint==2.12.2
pylint-celery==0.3
pylint-django==2.5.2
pylint-flask==0.6
pylint-plugin-utils==0.7
pyroma==3.2
PyYAML==6.0
requests==2.27.1
requirements-detector==0.7
setoptconf-tmp==0.3.1
smmap==5.0.0
snowballstemmer==2.2.0
stevedore==3.5.0
toml==0.10.2
tomli==2.0.1
types-requests==2.27.11
types-urllib3==1.26.10
typing_extensions==4.1.1
urllib3==1.26.8
vulture==2.3
wrapt==1.13.3

[chocoelho]

Hey there @gmankab, no-site-packages is not supported in the current mypy configuration in prospector. The way the config is working this way for a while without much change. To be easier to support an update mypy cli, the way options are implemented must change. The ideas you proposed sound like a fantastic way to start from.

[okuuva]

This is somewhat related to #446. Would be nice to provide path to mypy.ini and prospector would just pass that to the tool, this way prospector wouldn't necessarily have to implement config parsing for mypy at all. Or just implement a generic parser to pass given flags to the tool as is just like @gmankab suggested.

[gmankab]

The ideas you proposed sound like a fantastic way to start from

it`s great :)

[sbrunner]

There are many mypy options that are not handled by Propsector, should we use generic code to handle all the to mypy options?

[carlio]

I think that would make sense, I imagine it'd require finding those option values from mypy internals but a lot of prospector involves accessing private APIs. I didn't write this integration so I'm not completely sure how it works.

[sbrunner]

OK, when I have some time I will start some deeper investigations :-)

[sbrunner]

Fixed with #682