Dinnerbone / mcstatus

A Python class for checking the status of an enabled Minecraft server
http://dinnerbone.com/minecraft/tools/status/
1.11k stars 146 forks source link

Switch type checker to pyright #199

Closed ItsDrike closed 2 years ago

ItsDrike commented 2 years ago

As discussed in #182, the pytype type 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 pyright with pyright development dependency, which is there because pyright is written in type script, and it would normally need to be installed with npm, 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.