Switch type checker to pyright #199
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- This includes the original black formatter check - Additionally, this adds pyright type check - This workflow also introduces caching to make running it a lot quicker since it will be installing all of the poetry dependencies every time it's ran. This is necessary to prevent "import doesn't exist" errors from pyright.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #182, the
pytypetype checker isn't ideal and has many weird behaviors which ended up causing multiple issues when type-checking the code, even though the code did actually make sense type-wise. That's why it was decided that rather than adding a bunch of ignores everywhere just to satisfy pytype, it made a lot more sense to simply switch the type-checker to something different. Pytype is also quite a lot slower in comparison to other options which made the need to switch even more appealing.This PR removes pytype and instead uses
pyrightwith pyright development dependency, which is there because pyright is written in type script, and it would normally need to be installed withnpm, so instead this python dev dependency makes this installation easy even without node and npm on users machines. It also allows it to be used with tox's virtual environments.Edit:
After approval on discord, this PR now also includes a new github workflow to run pyright for each pull request or push into the repository. I decided to merge the original black workflow into it too, as it would be a waste of resources to run multiple workflows each installing python when it can be done in a single one.
Unlike the original black workflow which only installed black using pip, this workflow installs all of the dependencies for this project using poetry since pyright would be reporting unknown imports if we didn't do that. However because of this, the time it would take for this workflow to run is a lot longer as it needs to first install all of the projects dependencies, so to speed things up, I've also a logic to cache the poetry environment so that it can be reused in other workflows, as long as poetry.lock (and other conditions documented in the workflow directly) stay the same.
This means that this workflow could eventually even include running of the unit tests with pytest, and perhaps even the entire tox sweet, however I didn't add that in since that isn't what this PR is for.