Why not just use mypyand "pytest`? What are the advantages of the "pytest-mypy" package?

[simon-liebehenschel]

Sorry for my noob question, but what is the purpose of the package?
I can run in a terminal locally or at a cloud's CI/CD the following two commands:

>  mypy src/ && mypy tests/
>  pytest tests/ 

So why waste time on a new package development instead of just running two simple commands?

[dmtucker]

I think the main appeal is that this, and plugins like it (e.g. pytest-flake8, pytest-pylint, pytest-bandit, etc), enables the running of all your checks/tests with one command. For example:

pipenv run pytest --mypy --flake8 --pylint --bandit src/ tests/  # run the tests and static checks

That said, I see applications and other projects that target a single Python version as the primary audience.
I expect most multi-Python projects use a dedicated environment for static checks to avoid rerunning them unnecessarily:
https://github.com/dbader/pytest-mypy/blob/7fdc974f41be7c1e10175b7ae33b361688315df4/tox.ini#L137

tox -e py37,py38,py39  # run the tests (with each Python version)

https://github.com/dbader/pytest-mypy/blob/7fdc974f41be7c1e10175b7ae33b361688315df4/tox.ini#L148-L156

tox -e static  # run the static checks (only once)

As for development, @dbader made the package, and I found it interesting.
I use pytest a lot, and maintaining this has helped me learn 🙂

[LourensVeen]

I use this plugin, and a few more for my favourite linters, to run all the checks in a single command as @dmtucker described.

This has several advantages:

• I don't accidentally forget to run one of them and miss an issue that I later have to go back and fix
• External contributors unfamiliar with my setup can run a single command to check their changes, rather than having to learn about how exactly this project tests and lints and typechecks its code and do it manually
• I call the same command on my Continuous Integration infrastructure, giving me a single place to add or remove tools that applies everywhere

I do actually use this for projects that support a range of Python versions; I just run pytest with all the plugins in an appropriate container on the CI. The checks are fast anyway, so it's no big deal. It's true that I should get rid of that setup and move to tox though, I just haven't got a sufficiently round tuit yet :-).

So thanks to @dmtucker and @dbader and the other contributors for this useful tool!

Maybe we could consider this issue a request for adding a few lines on "What is this for?" to the README?

[blubberdiblub]

FWIW, PyCharm doesn't provide a mypy Run Configuration, but it does provide a pytest one.

Furthermore, it doesn't have a Run Configuration to run some arbitrary executable or script in an arbitrary way without limitations or strange peculiarities. It does have a Shell Script Run Configuration that can indeed be abused to do that, however, that's not the intent of that.

Therefore, this module can be a simple way to integrate an explicit mypy run (as opposed to another real-time background inspection) with PyCharm.

[simon-liebehenschel]

FWIW, PyCharm doesn't provide a mypy Run Configuration, but it does provide a pytest one.

Wow, why someone may need mypy configuration? Mypy is a static type checker with its settings file, I have no idea what someone may want to configure for it in a "Run configuration".

Furthermore, it doesn't have a Run Configuration to run some arbitrary executable or script in an arbitrary way without limitations or strange peculiarities. It does have a Shell Script Run Configuration that can indeed be abused to do that, however, that's not the intent of that.

Therefore, this module can be a simple way to integrate an explicit mypy run (as opposed to another real-time background inspection) with PyCharm.

It looks like you are reinventing here pre-commit.

---

Issue conclusion

People, thank you for all your answers.

I made a conclusion that pytest-mypy is a kind of alternative without any significant difference and without any valuable advantages. So, I will keep using pytest and pre-commit (that includes mypy, black, isort, etc.) in my company in all my CI/CD.

With consideration of all the above I am closing the issue.

[LourensVeen]

I made a conclusion that for me pytest-mypy is a kind of alternative without any significant difference and without any valuable advantages.

FTFY

[blubberdiblub]

Wow, why someone may need mypy configuration? Mypy is a static type checker with its settings file, I have no idea what someone may want to configure for it in a "Run configuration".

A Run Configuration is just an entry/item in PyCharm that can easily be executed with the press of a button (or menu entry, or shortcut, whatever), similar to how you execute a debug, coverage, profiling or any other "Run" for that matter.

It looks like you are reinventing here pre-commit.

That is based on the assumption that I only want to see mypy output just before I want to commit, which isn't generally true. For instance, I may want to iteratively work on a commit and check mypy or pytest results in between, for which "runs" in PyCharm are well-suited. And there are other instances for which one may not want a strict reliance on commits.

I was just giving a use case and therefore another justification for the existence of the package. It's not applicable for everyone and that's ok.

[simon-liebehenschel]

Wow, why someone may need mypy configuration? Mypy is a static type checker with its settings file, I have no idea what someone may want to configure for it in a "Run configuration".

A Run Configuration is just an entry/item in PyCharm that can easily be executed with the press of a button (or menu entry, or shortcut, whatever), similar to how you execute a debug, coverage, profiling or any other "Run" for that matter.

It looks like you are reinventing here pre-commit.

That is based on the assumption that I only want to see mypy output just before I want to commit, which isn't generally true. For instance, I may want to iteratively work on a commit and check mypy or pytest results in between, for which "runs" in PyCharm are well-suited. And there are other instances for which one may not want a strict reliance on commits.

I was just giving a use case and therefore another justification for the existence of the package. It's not applicable for everyone and that's ok.

Thank you for valuable reply. I run directly pre-commit run --all-files from terminal. Perhaps I will try your way some day.