Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add plugin configuration through pyproject.toml? #133

Open
Delgan opened this issue Sep 24, 2023 · 5 comments · May be fixed by #135
Open

Add plugin configuration through pyproject.toml? #133

Delgan opened this issue Sep 24, 2023 · 5 comments · May be fixed by #135

Comments

@Delgan
Copy link
Contributor

Delgan commented Sep 24, 2023

Hi!

I need a dedicated mypy.ini configuration for tests run by pytest-mypy-plugins. This configuration includes parameters like force_uppercase_builtins = true, which are very useful for unit tests but irrelevant for the entire project.

Currently, I can create a separate mypy-tests.ini file and run pytest with the --mypy-ini-file option. To avoid typing this every time, I can add addopts = "--mypy-ini-file=mypy-tests.ini" to my pytest.ini configuration.

However, there is a drawback to this approach: the path is resolved relative to the current working directory, not to pytest.ini. This can lead to surprising behavior, where test output changes depending on where the pytest command was executed. For example, running tests from outside the project's root folder may cause Mypy tests to fail (because it won't use the required mypy-tests.ini file) although all others ran seamlessly.

I'd like my tests to be robust in such cases. Pytest itself works flawlessly, so I believe plugins should too. I assume resolving the --mypy-ini-file path relative to the "rootdir" is not acceptable for a command-line option. Therefore, it seems appropriate to allow configuration via a file and, in this case, resolve the paths relative to that file. We could even imagine a "override mypy config" entry to avoid the additional mypy-tests.ini file in my scenario.

What are your thoughts on this?

I've noticed that pytest-mypy-plugins already depends on tomlkit, so I assume implementing this shouldn't be overly complicated.
However, I understand if you prefer not to add complexity to the plugin configuration in this way. Yet, If you're open to the idea, I'd be happy to contribute with a PR.

@Delgan Delgan changed the title Add configuration through pyproject.toml? Add plugin configuration through pyproject.toml? Sep 24, 2023
@sobolevn
Copy link
Member

sobolevn commented Sep 24, 2023

Does --mypy-pyproject-toml-file not work for you?

@Delgan
Copy link
Contributor Author

Delgan commented Sep 24, 2023

The problem would remain the same. Sorry if my description of the issue is not clear.
It's not about using mypy.ini or pyproject.toml, that's not really relevant here.

To put it more simply, I would like to configure pytest-mypy-plugins itself through pyproject.toml instead of using command-line options.

This would prevent tests from passing or failing depending on the current working directory, due to the way relative paths are resolved for --mypy-pyproject-toml-file and --mypy-ini-file.

@sobolevn
Copy link
Member

Oh, I see :)
PR is welcome!

@Delgan
Copy link
Contributor Author

Delgan commented Sep 24, 2023

Great, thanks! I'll work on it.

@Tinche
Copy link

Tinche commented Nov 24, 2023

Nice! I'm in the process of adding this plugin to the cattrs test suite and I think I want this.

To explain my use case: I want to run Mypy only on a single version of Python, say the latest. It's good enough and keeps complexity down. But I need to use --mypy-only-local-stub.

So my plan was to install the plugin only on 3.12 and put --mypy-only-local-stub into pyproject.toml/[tool.pytest.ini_options].addopts. But if I do that, on other Pythons pytest doesn't know what that argument is and won't run.

I'm sure there are other ways of solving this but this seemed like the simplest/most correct to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants