Run type-annotation linters in CI environment

[happz]

The goal si to verify the code and its annotations are compatible with Python packages shipped as system packages.

Pull Request Checklist

• [ ] implement the feature
• [ ] write the documentation
• [ ] extend the test coverage
• [ ] update the specification
• [ ] adjust plugin docstring
• [ ] modify the json schema
• [ ] mention the version
• [ ] include a release note

[LecrisUT]

How about bumping some of the minimum requirements?

• jinja2 >= 3.0: can get rid of types-jinja2
• types-jsonschema might not be necessary anymore? Seems like the simple typing are merged (primary issue), and it's mainly quite advanced typing that we most likely will not use that is still open.
• types-urllib3 can be removed once urllib3 >= 2.0 is landed. Epel9 might be tricky though.
• types-babel can be removed from 2.12.1. Didn't find what the version is on Epel9, F39 can remove already
• types-setuptools :shrug: what is this one used at?
• types-docutils, types-Markdown, types-requests still needed for the foreseeable future.

But does mypy not have a more to automatically download the missing typings from typeshed?

[happz]

How about bumping some of the minimum requirements?

As long as they can be satisfied with RPMs available to us, I don't see a problem in general. I'm not sure what would happen if we bump a package version too much, rpmbuild would fail?

• jinja2 >= 3.0: can get rid of types-jinja2
• types-jsonschema might not be necessary anymore? Seems like the simple typing are merged (primary issue), and it's mainly quite advanced typing that we most likely will not use that is still open.
• types-urllib3 can be removed once urllib3 >= 2.0 is landed. Epel9 might be tricky though.
• types-babel can be removed from 2.12.1. Didn't find what the version is on Epel9, F39 can remove already
• types-setuptools 🤷 what is this one used at?

Maybe something related to reousrce_files, importlib? I don't recall we'd use packaging-related functionality in tmt code for anything beyond that.

• types-docutils, types-Markdown, types-requests still needed for the foreseeable future.

But does mypy not have a more to automatically download the missing typings from typeshed?

It does download missing types, with --install-types, on the other hand it seemed better to list them explicitly and make sure they are present in mypy and pyright environments rather than leave it on linter guessing.

[LecrisUT]

• types-setuptools 🤷 what is this one used at?

Maybe something related to reousrce_files, importlib? I don't recall we'd use packaging-related functionality in tmt code for anything beyond that.

types-setuptools seems to only cover pkg_resources and distutils, both of which tmt seems to have already upgraded. That's why I was asking.

But does mypy not have a more to automatically download the missing typings from typeshed?

It does download missing types, with --install-types, on the other hand it seemed better to list them explicitly and make sure they are present in mypy and pyright environments rather than leave it on linter guessing.

Good to keep this option in mind. If we end up decommissioning the pre-commit in favor of this workflow, that might be necessary to get the typeshed. At the very least it is worth making a temp commit running it with --install-types to see if it uses the restrictions as described in the previous comment

Edit: Did a bit of navigation around install_types and it seems it does not include the version constraint ^1, and the typeshed packages are not version matched to the original package (the intent upstream there is that the typeshed have no executable code, including the original package). So some kind of logic to search for the missing stubs and manually create the requirements.txt might be needed.