Config settings for gradual adoption

[jrheard-seesaw]

Hi! I'm interested in trying out Pyright+Pylance. I'm trying to figure out a plan for gradual adoption in a preexisting codebase; I basically want to set typeCheckingMode: "standard" for a small handful of (potentially deeply nested) directories to start off, and then gradually grow that list of directories over time.

In mypy, I would do something like this in my mypy.ini:

[mypy]
strict = True
ignore_errors = True

[mypy-util.some_directory.*]
ignore_errors = False

[mypy-backend.models.validation.*]
ignore_errors = False

I'm trying to figure out how to achieve a similar setup with Pyright/Pylance.

I have a pyrightconfig.json that looks something like this:

{
    "include": [
        "backend/models/validation"
    ],
    "pythonVersion": "3.11",
    "pythonPlatform": "Linux",
    "typeCheckingMode": "standard",
}

That config file causes command-line Pyright to behave the way I want, but when editing files in some other directory (eg util/some_directory/foo.py), the Pylance extension is reporting type errors that I don't want to see because I'm not yet ready to fix them.

What should I do differently to cause Pylance and Pyright to both behave the same way (i.e. not report type errors for any directories except the ones listed in my "include" list)?

Thank you!

[rchiodo]

I believe that should work except that when you open a file in the IDE, it's automatically included. Open files count towards what we analyze.

You could also add an ignore section, but then you get no diagnostics for the util folder:

{
    "include": [
        "backend/models/validation"
    ],
    "ignore": ["util"],
    "pythonVersion": "3.11",
    "pythonPlatform": "Linux",
    "typeCheckingMode": "standard",
}

I think what you really want is this enhancement request:

microsoft/pylance-release#5564

That way you could have different pyrightconfig.json files at different folders to set the typecheckingmode for each.

[rchiodo]

It's not ideal though because then everybody else can introduce strict mode bugs in the IDE and they don't realize it until they submit to CI. I think the ideal solution would be for us to have support for pyrightconfig.json in multiple directories.

[jrheard-seesaw]

The glob idea is interesting! Do you think that an approach like this could work?

    "include": [
        "backend/models/validation",
        "util/foo/bar",
    ],
    "ignore": [
        "backend/!(models/validation)/**",
        "util/!(foo/bar)/**"
    ],

I'm not super skilled with glob patterns, but from some poking around so far it seems like some tools would interpret globs like that in a way that would accomplish my goal. It looks like the relevant pyright code (assuming that I found the right code) doesn't implement this ! behavior, so I guess that won't be an option for me here.

(Please let me know if my glob syntax is incorrect or if I'm totally mistaken about the ability for this to be expressed in any known version of glob syntax!)

Do you think that it could be worthwhile to open an issue asking for pyright to support exclamation points in glob patterns seen in its config file? Or is my use case too niche / am I approaching this from the wrong angle?

[rchiodo]

I would guess that Eric would say to use include patterns to implement the ! patterns for ignore. Like he mentions here:
#6851 but that doesn't seem to work for ignore. Ignore seems to trump include, which I guess makes sense.

So I think you'd need ! support for at least ignore.

[erictraut]

For general guidance in applying gradual adoption of type checking, refer to this documentation.

If you want to exclude certain files or directories from the project, you can use the exclude, but I don't recommend that approach. Instead, I recommend enabling a few diagnostic checks for your entire project, then gradually add diagnostic rules as you fix type issues in your code. If a particular file is too problematic (e.g. contains significant dynamic code), you can explicitly disable specific diagnostic checks for that file using a file-level comment.

This is the approach I've used successfully for gradually adopting typing for several large Python code bases.

[jrheard-seesaw]

Interesting! I'll take a step back and start again with that approach. My original plan was to immediately turn the checks up to 11 and then gradually roll out coverage on a file-by-file basis; I hadn't considered rolling out coverage on a check-by-check basis, I'll try that instead. Thanks for the advice!