python / typeshed

Collection of library stubs for Python, with static types
Other
4.37k stars 1.75k forks source link

Pin stubs to their corresponding upstream version #12694

Open sk- opened 1 month ago

sk- commented 1 month ago

Now that third party stubs are released as individual packages it would be great if the package included the upstream version range as an install requirements.

Currently the generated stubs contain a paragraph indicating the version they are intended for but, no such restriction is present in the setup.py file.

Issues #5768 and #5618 discuss allowing external dependencies, but they only allow to specify dependencies that are in fact dependencies of the corresponding upstream package, not the upstream package itself. In the example below it can be seen how types-requests depends on urllib3, but not on requests itself.

Adding the upstream package is important, as currently many teams use automated tools like Renovatebot or Dependabot to manage their dependencies, and without the explicit requirement you may end up with inconsistent deps. In our case someone in our team updated the types for protobuf to version 5.26, but we are restricted to use version 4.25. One could argue that any incompatibilities should be caught by CI, and it's true. But there's another case that is not prevented. First you upload the types of protobuf to the latest version, CI does not catch any errors, because you are using a small part of the library. Some time later you start working on a new feature and use a function or parameter that is only defined in the latest version. You write a test and it fails, and you end up scratching your head for a long time not understanding why that function/param is not present.

Examples

Requests Screenshot 2024-09-26 at 8 07 06 AM Screenshot 2024-09-26 at 8 10 29 AM
Cachetools Screenshot 2024-09-26 at 8 11 24 AM Screenshot 2024-09-26 at 8 09 18 AM
srittau commented 1 month ago

There are some problems I can see:

I think we could experiment with only specifying the lower limit for now. Maybe we can later extend our metadata to be able to specify an upper limit or an upper limit algorithm in some way.

hauntsaninja commented 1 month ago

I'd be opposed to this by default, but I'd be willing to add e.g. an upstream extra, so folks who want this can do types-requests[upstream] and let their package manager's resolver try its best.

JukkaL commented 1 month ago

I've seen projects use stubs targeting an older version than the installed version of a library, since updating stubs can sometimes take significant effort. In particular, a new version of stubs can have new (or modified) type annotations that trigger false positives. A large project may depend a huge number of third-party libraries, and not keeping stubs and implementations always in sync (at least temporarily) can be an acceptable form of technical debt in some contexts, I think.

Avasam commented 1 month ago

I was also initially opposed to this as well for the reasons already mentioned, but then I also thought this could be done through extras, as it would be opt-in.

Maybe also only though a lower bound in the extra, since it's expected that typeshed stubs versioning will fall behind. Using the same version specification as found in METADATA.toml (with the *) could also work. I could see myself using that.