Conversation
|
This version of mypy is not released for Python 3.6 . So we need to add a conditional, one way or the other... Apart from that, we can also search which was the first version that was broken by our stubs. I don't have much time right now for this, though. |
|
Locally here in Linux, 0.940 is the first version to |
| "pytest", | ||
| "pytest-xvfb", | ||
| ], | ||
| }, |
There was a problem hiding this comment.
I did not know you can do things like this. Nice!
There was a problem hiding this comment.
See the env_var list at https://peps.python.org/pep-0508/.
env_var = ('python_version' | 'python_full_version' |
'os_name' | 'sys_platform' | 'platform_release' |
'platform_system' | 'platform_version' |
'platform_machine' | 'platform_python_implementation' |
'implementation_name' | 'implementation_version' |
'extra' # ONLY when defined by a containing layer
)
Though it appears this boundary may belong closer to 0.981 python/mypy@dc118e2.
|
I am convinced that we should have a very stable mypy for our tests, and one CI job with failure allowed for testing latest mypy. Until this is fixed, 0.930 is our good version then. |
|
Dependabot style automatic PRs are an alternative to consider instead of having 'latest version' jobs. But, there are upsides to all of various approaches to this. Reported the segfault upstream. https://www.riverbankcomputing.com/pipermail/pyqt/2022-November/045068.html I'll take a look at a stubtest wrapper that monkey patches to disable the class finality test. |
|
segfaults gone... now just 2853 regular stubtest errors. Hopefully my comments around the dependency versions in |
|
At least it passes with Python 3.6 |
|
Note that there's mypy 1.0 now as well. Depending, it may be better to work this intermediate step, or may be better to just get to 1.0 directly. |
No description provided.