Hi, thanks for the PR.

I had a bit of time and tried this out. I couldn't make it work though, for some reason the plugin gives me a notice "executable ... not found" for any path I try, even though the path obviously exists. Possibly PEBKAC, I will try again when I have more time.

Thanks for looking at it. I will double check that it works and will try to also do it under Linux (I mainly use Windows).

@intgr , I got some time to look into it. The problem is in Linux system. Kind of. ;) I was able to reproduce the problem from a terminal:

1. If I simply run /usr/bin/mypy -V, then it works.
2. If I do /something/something/venv/bin/python /usr/bin/mypy -V, then it doesn't work. python here is inside a virtual environment without mypy in it.

There is this code in the plugin:

I think that the whole process of executing mypy should be simplified:

1. If user didn't provide a custom path, do what is done today: check current python environment, auto-detect system-wide mypy.
2. If user provided a custom path, try to use that path directly. If it doesn't work, try to use it as current_python custom_mypy_path.

Either way, add --python-executable argument to mypy, which would point to project's interpreter. This will ensure correct packages could be imported by mypy.

I agree, the isWindowsExecutable check is suspicious. It was apparently added in #16 to fix bug #15. Apparently in Windows, mypy's entry point mypy.exe is a binary file rather than a Python script.

The issue I had with 'executable "/usr/local/bin/mypy" not found' on macOS #99 (comment) seems to stem from the same root cause as #15:

2022-03-26 14:49:53,294 [ 245192]   INFO - .pycharm.mypy.mpapi.MypyRunner - Detected Mypy path: /usr/local/bin/mypy 
2022-03-26 14:49:53,387 [ 245285]   INFO - .pycharm.mypy.mpapi.MypyRunner - Command Line string: /usr/local/bin/python3.9 /usr/local/bin/mypy -V 
2022-03-26 14:49:53,387 [ 245285]   WARN - .pycharm.mypy.mpapi.MypyRunner - Error while checking Mypy path: Traceback (most recent call last):
  File "/usr/local/bin/mypy", line 5, in <module>
    from mypy.__main__ import console_entry
ModuleNotFoundError: No module named 'mypy' 

Peering into /usr/local/bin/mypy gives a clue: a globally installed mypy script itself is supposed to know the correct Python interpreter:

#!/usr/local/Cellar/mypy/0.940/libexec/bin/python3.10

But this plugin tries to invoke it with the project's interpreter, which does not have mypy installed locally.

I think that the whole process of executing mypy should be simplified

You're on the right track. The plugin should distinguish between two different ways how mypy can be installed:

1. If mypy is installed in a virtualenv, invoke mypy via the virtualenv's interpreter: $VIRTUAL_ENV/bin/python $VIRTUALENV/bin/mypy ...
2. If mypy is installed globally, invoke the mypy binary directly without specifying a Python interpreter. Similar to the isWindowsExecutable condition, but should behave the same on all OSes.

So the question is, how to distinguish between (1) and (2). Perhaps we can get away with assuming that when a custom path is specified, it's referring to a global mypy installation?

Or make some attempt to detect whether the specified path is a virtualenv path? Seems fragile to me. But it sounds like a legitimate use case that someone may want to have a special virtualenv that contains mypy, and use that in multiple projects.

Perhaps the settings UI should be redesigned to offer three options:

• Specify globally installed mypy by path, executed as (2) (e.g. my use case with /usr/local/bin/mypy)
• Dropdown to select between virtual envs configured in PyCharm, these would be executed as (1)
• (Default) Auto-detect: if the project's virtualenv contains mypy run it as (1), otherwise try to detect a global mypy installation in PATH environment variable and run it as (2).

Either way, add --python-executable argument to mypy, which would point to project's interpreter

Agreed, this is a good idea. But it solves a different problem and should probably be a separate pull request.

Closing this since it seems to be addressed by #111