Skip to content
New issue

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

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

Already on GitHub? # to your account

Split import-untyped into two different error codes depending on whether stubs are available to install #18661

Open
jtherrmann opened this issue Feb 11, 2025 · 0 comments
Labels

Comments

@jtherrmann
Copy link

Feature

Implement separate error codes for (1) untyped imports without stubs available and (2) untyped imports with stubs available.

Pitch

As explained under Missing imports in the docs, there are two different categories of untyped imports. Currently, both of these categories are grouped under the import-untyped error code. For example:

  1. No stubs available (documented here):

    error: Skipping analyzing "boto3": module is installed, but missing library stubs or py.typed marker  [import-untyped]
    
  2. Stubs available (documented here):

    error: Library stubs not installed for "requests"  [import-untyped]
    note: Hint: "python3 -m pip install types-requests"
    

I propose that these categories should fall under different error codes, either by changing the error code for both of these categories (and removing the import-untyped error code) or by changing the error code for only one of the categories, and leaving the other as import-untyped. For example, the second category could fall under a new import-untyped-stubs-available code.

This would allow configuring mypy to handle these two categories differently. For example, I would like to always ignore errors for untyped third-party libraries without stubs available, but always show errors for libraries with stubs available, so that I know which stub packages I should add to my project dependencies. The available solutions for achieving this all have drawbacks:

  • Using disable_error_code = import-untyped ignores both of the above categories, so you won't be notified about libraries with available stubs.
  • Using the --install-types option as part of CICD workflows is brittle and not recommended (see Option "install-types" breaks project version dependencies. #17852), so doesn't scale well when maintaining many different repositories where running --install-types locally for every project on a regular basis is not feasible.
  • Ignoring the import-untyped error code for individual imports is again inconvenient when managing many different projects with many third-party dependencies. Also, if you ignore the import-untyped error code for a particular import and then the library later adds type stubs, mypy won't notify you that there is a stub package available to install.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant