Skip to content

Composing multiple configuration files #9620

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

Open
cihati opened this issue Oct 20, 2020 · 4 comments · May be fixed by #19135
Open

Composing multiple configuration files #9620

cihati opened this issue Oct 20, 2020 · 4 comments · May be fixed by #19135
Labels
feature topic-configuration Configuration files and flags

Comments

@cihati
Copy link

cihati commented Oct 20, 2020

Feature

Ability to specify a base configuration file and another one to override/extend behavior.

Pitch

We have a monorepo with Gradle. There are a few different Python projects and each of them define their linters either fully duplicated or only with slight differences. I'd like to standardize this. For mypy, I'd like to have a base configuration file where I define common settings, and then make it possible to have projects overriding/extending behavior.

For instance, one project uses Django, and it has django-stubs plugin for mypy. If I put this into the base config, then mypy complains on the non-Django projects as the plugin becomes unusable. I do know that I can override some configuration behavior through command line arguments ("Settings override mypy’s built-in defaults and command line flags can override settings.") but I'm not sure if it's possible for plugin settings anyways.

@The-Compiler
Copy link
Contributor

We have a similar situation in qutebrowser (cc @toofar), where we want to support different major versions of a library via something like:

if machinery.USE_PYQT5:
    from PyQt5.QtCore import *
elif machinery.USE_PYQT6:
    from PyQt6.QtCore import *

Stubs are available for both PyQt5 and PyQt6, so we'd like to run mypy twice, once with --always-true=USE_PYQT5 --always-false=USE_PYQT6, and once with the opposite.

There are other wrappers over PyQt5/PyQt6 which share the same approach, and usually ship a command-line tool on top of mypy to generate flags to pass to it: qts (cc @altendky), qtpy.

However, it'd be nice to have a default setting for that (so that mypy can be run, even from e.g. an editor integration, without needing a wrapper). Then there could be a config snippet overriding those again.

Unfortunately, in our case, even having a default in the config and overriding it on the commandline won't work properly, as:

mypy: error: You can't make a variable always true and always false (IS_QT5, IS_QT6, USE_PYQT5, USE_PYQT6)

but I suppose that's different from what this issue describes.

@AlexWaygood AlexWaygood added the topic-configuration Configuration files and flags label Aug 29, 2022
@ruslaniv
Copy link

ruslaniv commented Apr 9, 2024

Yes, this is required for monorepos badly!
It would be great to implement it like Ruff does, where you can keep the main config file in the root and then project specific configs in the project folders and then just do:

extend = "../mypy.ini"

@Avasam
Copy link
Contributor

Avasam commented Aug 3, 2024

I'll add that even across multiple repositories, this can enable shared based configuration through git submodules.

@ericmburgess
Copy link

ericmburgess commented Sep 26, 2024

Yes, please! Lack of this capability is the only thing in the way of my practice of keeping a scratch folder in each repo, which will be totally ignored by git and mypy. It's important that I can configure this without modifying anything that is checked in to source control. Currently I have simply duplicated the (git tracked) .mypy.ini with a git-ignored mypy.ini (no dot) file, and added my personal ignores. But this is brittle since I can forget to update my replacement config when the real one is changed.

@hasier hasier linked a pull request May 23, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature topic-configuration Configuration files and flags
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants