Consider vendoring third-party typeshed stubs, too

[aidandj]

Summary

Given this small code block:

import grpc

try:
    something = 1
except grpc.RpcError as e:
    e.code()

I'm getting this error: warning[unresolved-attribute]: Type RpcErrorhas no attributecode``

This type exists in typeshed and pyright seems to pick it up and does not complain. But ty does.

Version

ty 0.0.1-alpha.19 (e9cb838 2025-08-19)

[AlexWaygood]

Thanks for the report!

This type exists in typeshed and pyright seems to pick it up and does not complain. But ty does.

The difference here is that pyright vendors all of typeshed's third-party stubs. Ty instead currently follows mypy's model of only vendoring typeshed's stdlib stubs. That means that we're using the runtime source code for the grpcio library rather than typeshed's stubs for grpcio. The good news, however, is that typeshed publishes its grpcio stubs to PyPI -- installing types-grpcio into your Python environment before running ty should get rid of the AttributeError. If you're invoking ty using uv and you have it listed as a dev-dependency, it might be as simple as listing types-grpcio as a dev-dependency too -- or you could run uv run --with=types-grpcio ty check rather than uv run ty check.

[AlexWaygood]

Ideally I feel like we'd emit a better diagnostic here, but I'm not totally sure how. It would be fairly easy to have an up-to-date list of third-party modules for which typeshed stubs exist, and suggest to the user that they install them whenever we emit an unresolved-import diagnostic for one of them. (We would update the list every time we sync our vendored copy of typeshed's stubs.) But this situation doesn't result in an unresolved-import diagnostic (grpcio is not a C extension), it results in an unresolved-attribute diagnostic. Installing typeshed's stubs for a dependency might help with an unresolved-attribute diagnostic, but in some cases it also might hurt -- you can't say for sure like you can with an unresolved-import diagnostic.

We also haven't ruled out vendoring all of typeshed's third-party stubs, like pyright does. It would obviously have the benefit that it's what users of pyright will probably expect. It has the disadvantage that it would increase our binary size and possibly make it harder to reproduce type-checking results across machines.

[carljm]

and possibly make it harder to reproduce type-checking results across machines.

Why would it have that effect?

[aidandj]

Thanks for the clarification. I actually tried running it using the --typeshed argument, and got the same error. I now read the documentation closer and see that it does clarify that the typeshed argument only applies to stdlib.

Although I probably agree that installing individual 3rd party stubs is the "correct" approach, I foresee a very large number of duplicate issues as people make a switch from pyright to ty. I like the idea of keeping a list of 3rd party stubs as things get vendored. That would let you report an error similar to one that typescript sometimes throws, "have you tried installing types-<package-x>"

If typeshed is already being vendored, then it isn't really an added complication to maintain that list, once code is written once.

[AlexWaygood]

and possibly make it harder to reproduce type-checking results across machiness

Why would it have that effect?

Different versions of ty might have different versions of the grpcio stubs vendored with them, but it might not be immediately obvious to users that two different developers are implicitly using two different versions of the grpcio stubs because one of them hasn't upgraded to the latest version of ty.

Forcing users to explicitly list a stubs package as a dev-dependency means that the user knows exactly what version of the stubs they're using, it means that the stubs package is explicitly listed with its version if a user does something like uv pip list, and it means that a team of people all people working on the project can easily ensure they'll all be using exactly the same version of those stubs (it'll be pinned in their uv.lock file if they're using uv!).

[carljm]

Ah, ok, I wondered if you were thinking of differing ty versions. I'm not sure how much to weight that as a concern -- it's inherently the case (just because of behavior changes in ty itself!) that if you have different developers using different ty versions, they're likely to get differing results.

[AlexWaygood]

Yeah -- FWIW, the last time we had this discussion as a team I argued that LSP users would probably be expecting to have all of typeshed's third-party stubs vendored, like pyright, and that the benefits of doing so probably outweighed the costs given that we wanted ty to work great as an LSP as well as a CLI tool. I think @MichaReiser was the strongest voice arguing against doing that for now.

[aidandj]

FWIW, users should also be locking the ty version if they want to maintain consistency between runs. This can be an issue when just using an LSP, unless the LSP can use the locally installed version. So if one were to lock the ty version that would provide the same version locking as locking individual stub packages.

[AlexWaygood]

And vendoring the third-party stubs doesn't prevent a user from installing a different version of those stubs if they want to. The installed third-party stubs would take precedence over any vendored third-party stubs, as per the spec

[MichaReiser]

I think @MichaReiser was the strongest voice arguing against doing that for now.

The concern I raised was that I'm not sure if bundling all stubs with ty is the right solution if we're mainly concerned about LSP only users where we could bundle the stubs as part of the VS Code extension instead (or download them on demand or something else)

[aidandj]

I think having differing output when running ty check, and LSP output is confusing behavior. Someone is going to see no errors in Vscode, push code, and have CI fail.