Skip to content

proposal: add more CI tooling for type safety, formatting, linting, and test coverage #81

@dpaiton

Description

@dpaiton

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions