Skip to content

Use mypy.stubtest in CI #25

New issue

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

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

Already on GitHub? Sign in to your account

Merged
merged 20 commits into from
Apr 18, 2025
Merged

Use mypy.stubtest in CI #25

merged 20 commits into from
Apr 18, 2025

Conversation

lagru
Copy link
Member

@lagru lagru commented Mar 12, 2025

The goal here is to run docstub on its own codebase and check the resulting stubs with mypy. So far it's been a good way to highlight a few missing features.

@lagru lagru added enhancement New feature or request devops Infrastructure, tooling, ... labels Mar 12, 2025
@lagru lagru mentioned this pull request Mar 12, 2025
28 tasks
@lagru lagru marked this pull request as draft March 12, 2025 13:07
lagru added 15 commits April 11, 2025 22:39
This enables using `# docstub: off` and `# docstub: on` comments – a way
to tell docstub to copy wrapped code unchanged into a stub file. Not
sure yet how useful this will be, but for now it's self-contained enough
and easy to remove.

What would be really nice, would be a way to override the output of
docstub in a similar manner – in case docstub doesn't do the right thing
or doesn't yet know how to.

E.g. to handle edge cases like attributes in enums etc.
Apparently, enums members should not include type annotations, instead
type checkers are supposed to infer the type from the assigned value
itself. Long-term, we might want to support Enums by default, but for no
use this not so satisfying workaround.
instead of each method manually. Also makes it possibly to wrap the
_docstub_comment_directives decorator and catch errors raised inside
it.
The transformer leaves the whitespace untouched, therefore we need
to account for that when comparing the output.
Qualnames should be usable in literals as well. E.g.,
a concrete Enum type.
docstub\._version\..*`
  Runtime differences with VERSION_TUPLE are picked up for some reason.
  I couldn't figure out a way to make these go away.

docstub\..*\.__match_args__$
  Seems to be triggerd by runtime difference in dataclasses

docstub._config.Config.__init__
docstub._docstrings.Annotation.__init__
docstub._stubs._Scope.__init__
  Likewise dataclasses, specifically related to default values not
  being included in stubs.

docstub._cache.FuncSerializer.__type_params__
  Seems to be a runtime difference due to the used generic

docstub._cli.main
  The runtime signature is picked up with *args, **kwargs, probably due
  to it being a click command
@lagru lagru force-pushed the use-mypy branch 2 times, most recently from 1c10c69 to 93c6542 Compare April 18, 2025 16:50
Per chance, it worked for the maxos and linux jobs, but not for the
windows one.

Don't know how `CI_PROJECT_DIR` snuck in, seems like that's the name
GitLab would use..
@lagru lagru marked this pull request as ready for review April 18, 2025 17:07
@lagru
Copy link
Member Author

lagru commented Apr 18, 2025

Okay, this isn't perfect yet. docstub currently doesn't deal with special cases like enums or dataclasses. mypy.stubtest is also picking up differences with runtime. I'm not sure whether those are false reports. If they are valid, I haven't yet attempted to fix them. Instead I'm
using stubtests --allowlist feature to whitelist them.

Another issue is, that mypy can only use stubs for checking when they are imported. Thus, mypy can't check for correct type usage in docstub itself it seems. But we should already be able to use the stubs to check the test suite. A workaround might be, to use inlined types. E.g. with libcst's apply_type_annotations or retype (no longer maintained).

For now this is good enough for a PR. Let's merge. 😊

@lagru lagru merged commit 6cad9c5 into main Apr 18, 2025
4 checks passed
@lagru lagru deleted the use-mypy branch April 18, 2025 17:17
@lagru lagru added this to the v0.3 (MVP) milestone May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devops Infrastructure, tooling, ... enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant