Stubs not found for installed typed library

[fcole90]

Possibly related to:

• Stub file not found on import but imported package has py.typed #555
• Editable installs (pip install -e) aren't fully supported #78

Environment data

• Language Server Pylance language server 2022.7.40 (pyright bd00e0d1)
• OS and version: Ubuntu 22.04
• Python version (& distribution if applicable, e.g. Anaconda): 3.10

Code Snippet

from gidocgen.gir.ast import Repository

repo = Repository()
repo.includes

Repro Steps

.vscode .vscode/settings.json

{
  "editor.autoIndent": "advanced",
  "editor.guides.indentation": true,
  "editor.tabSize": 4,
  
  "python.analysis.completeFunctionParens": true,
  "python.analysis.autoImportCompletions": true,
  "python.analysis.diagnosticSeverityOverrides": {
    "reportUnknownMemberType": "warning",
  },
  "python.analysis.typeCheckingMode": "strict",
  "python.analysis.useLibraryCodeForTypes": true,
  
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python3",

  "python.formatting.provider": "autopep8",
  
  "python.linting.enabled": true,
  "python.linting.lintOnSave": true,
  "python.linting.flake8Enabled": true,
  "python.linting.flake8CategorySeverity.E": "Hint",
  "python.linting.flake8CategorySeverity.F": "Error",
  "python.linting.flake8Args": [
    "--max-line-length=120",
  ],
  "python.linting.ignorePatterns": [
    "**/site-packages/**/*.py",
    ".vscode/*.py"
  ],
}

venv.sh

#!/usr/bin/env bash

VENV=".venv"
PYTHON=${PYTHON:-python3}

if [ -d "$VENV" ]; then
    . "$VENV"/bin/activate
else
    virtualenv --system-site-packages -p $PYTHON "$VENV"
    . "$VENV"/bin/activate
    pip install gi-docgen -I
fi

Install and setup with source venv.sh

Expected behavior

Stubs to be found and function correctly.

Actual behavior

PyLance reports not finding stubs, yet everything seems to be found correctly.

If I follow the advice to create stubs, a typings directory is created but then the types are inferred incorrectly.


Note how in the second picture fewer props are found (e.g. missing includes, c_includes).

Logs

Too long, uploading as a file: log.txt

[erictraut]

I've installed the latest version of the gi-docgen (version 2022.1), and it does not include a "py.typed" file marker as specified in PEP 561. Pylance will use the type information in the library, but since the library doesn't claim to be typed, the reportMissingTypeStubs rule emits an error.

I recommend contacting the maintainer of this library and suggesting that they include a "py.typed" file marker.

[fcole90]

Thanks, I'm going to send them a PR then 😊

However, I've two considerations for discussion.

1. Why is this an Error (by default) and not just a Warning, given that it's able to infer the types anyway?
2. Why does the "Quick fix" stub generation create stubs that are missing properties that were identified before that step (like in the example)? Instead of fixing the situation, it seems to make more damage.

[erictraut]

This isn't an error by default. You will see this error only if you enable the reportMissingTypeStubs diagnostic rule. This rule is disabled by default in pylance. I'm guessing that you have set python.analysis.typeCheckingMode to either "basic" or "strict" (since it is "off" by default). Here's a table that maps the type checking mode to the default severity level for each diagnostic rule.

When you use the stub creation mechanism, pyright (the type checker that underlies pylance) creates a "first draft" set of type stubs. You will typically need to make improvements to them manually. For more information about type stubs, refer to this documentation. Ideally type information is maintained by the library author and distributed with the library. That is increasingly common, although we're finding that many libraries that claim to contain type information (i.e. include a "py.typed" file) are incomplete in terms of typing. The command-line version of pyright includes a "--verifytypes" mode that library authors can use to identify missing type information within their library. For more details, refer to this documentation.

[fcole90]

Thank you very much for your thorough explanation! 😊

About the stub generation, yes, I was expecting it not to be necessarily complete indeed. What I found surprising was that many of the automatically inferred properties were lost in the process. Perhaps the code that generates the stubs and the one that suggests the props in the UI are using different inference rules? 🤔

[erictraut]

The stub generator does not emit inferred return types for functions or methods. Inferred types can be inaccurate, and our philosophy is that it's better to omit a return type annotation than to include an inaccurate one. By omitting a return type annotation, the developer can easily determine which types are missing and add them as needed. The stub generator does include a comment with the inferred type, so if you agree with the inferred type, you can simply uncomment it.

[fcole90]

Oh, I see now, makes sense. Again, thanks a lot for your explanations, I really appreciate that! 😊
Have a great weekend! 😊