I'd like to add the following processes to the sparsecoding CI:
- black
- code formatter; has nothing to do with syntax, but strictly enforces opinionated and unified code structure
- codecov
- utility to display on our README how much test coverage we have; this is a great way to shame developers into writing more tests
- pylint
- this can work alongside flake8, but should probably replace it due to high amount of overlap in utility. It is slower, but more comprehensive and configurable than flake8. Given the size of the repo, I think comprehensive is more important than speed.
- pyright
- python has been steadily improving their type system, and generally encourages using it for new projects. I also am a huge advocate for typing. This is the standard type checker.
each of these have pros & cons, but collectively my argument for them is that "guardrails" are really valuable when you're working on a code base with a large team, or in an open-source setting. Including these sorts of checks in CI forces PR code to adhere to standards, instead of the PR reviewer having to do it.
Of them, the likely two most controversial are pyright & pylint.
Pylint replaces flake8. I don't have super strong opinions on this; if y'all really like flake8 then lets stick with it. We could also consider the young gun ruff which has fewer checks, is less configurable, but is crazy fast and cool bc it's written in rust 😎.
pyright is a philosophy change in the repo. Existing non-typed code can stay (for now), but setting up pyright encourages us to maintain typing going forward, and improving typing on existing code as we develop. I am a big proponent of this -- I think it helps you find bugs way faster, it improves readability & onboarding, and it is the direction the language is going in general. Python releases, peps, etc are focusing a lot of energy on type safety.
I will take the steps to implement these if we have a consensus.
I'd like to add the following processes to the sparsecoding CI:
each of these have pros & cons, but collectively my argument for them is that "guardrails" are really valuable when you're working on a code base with a large team, or in an open-source setting. Including these sorts of checks in CI forces PR code to adhere to standards, instead of the PR reviewer having to do it.
Of them, the likely two most controversial are pyright & pylint.
Pylint replaces flake8. I don't have super strong opinions on this; if y'all really like flake8 then lets stick with it. We could also consider the young gun ruff which has fewer checks, is less configurable, but is crazy fast and cool bc it's written in rust 😎.
pyright is a philosophy change in the repo. Existing non-typed code can stay (for now), but setting up pyright encourages us to maintain typing going forward, and improving typing on existing code as we develop. I am a big proponent of this -- I think it helps you find bugs way faster, it improves readability & onboarding, and it is the direction the language is going in general. Python releases, peps, etc are focusing a lot of energy on type safety.
I will take the steps to implement these if we have a consensus.