Why is python -m used for flake8, pylint but not mypy

[vikigenius]

I was looking into #1974 and trying to understand how the python checkers were implemented

Looking at the code, I see that flake8 and pylint are called using python -m and using the stdin option when enabled.
But mypy is called directly as is.

Is there any reasoning for this? I looked through the issue #1055 but I am still not clear on what advantage you might get by using python -m over just calling the flake8 executable directly?

@cpitclaudel I would appreciate if you can shed some light on this.

[cpitclaudel]

Hi @vikigenius! Some answers:

• We use python -c, not python -m, for annoying PATH reasons (we have to pop . from sys.path)
• Users can still set the executable directly to flake8, etc.
• The reason we use -c instead of always calling the executable directly is that it makes it easier to configure which version of python gets used (you can set flycheck-pylint-executable to whichever version of python you want).
• I'm not sure why we don't do this for mypy, and the history isn't helpful

Arguably, this rationale matters less now that python 2 is dead, but I'm sure we still have users who depend on it (it was very useful for me a few years back in one class that I was teaching, to quickly switch between 2.7 and 3.6).

I would suggest doing the same for ruff, unless it breaks anything. As for mypy, it would be worth unifying it with the rest, unless it breaks something.

[vikigenius]

Hi @cpitclaudel thanks for the clarification I have a better understanding of how that works now.

So currently the issue is ruff does not seem to work when python -m ruff. So it's not going to work with python -c either. I will ask clarification on the ruff repo for it.

But if the author is not willing to support it, we could always use ruff the same way we are using mypy currently right?

[cpitclaudel]

But if the author is not willing to support it, we could always use ruff the same way we are using mypy currently right?

Sure, of course. Does ruff exist as a Python library, or just as a standalone program? If the former then -m/-c would make sense, but if it's the later then ruff makes sense.

I wrote:

I would suggest doing the same for ruff, unless it breaks anything.

… but I didn't realize that ruff was a Rust program. Given that (depending on how it's installed), concerns about virtualenvs and Python versions might not be relevant, and then python -c wouldn't be relevant at all.

[asmeurer]

python -m ensures that you are using the Python executable that you think you are. Otherwise you may be picking up a version of flake8 from the PATH that is loading a different Python. It's still relevant even post-Python 2 because of virtual environments. Using python -m is generally considered a best-practice. See https://snarky.ca/why-you-should-use-python-m-pip/

ruff doesn't depend on Python. It's a pure Rust project. So you would not use python -m ruff.

[wyuenho]

Does #1955 solve this problem?