Skip to content

Integrate code quality tools (black, isort, ruff) #570

Description

@juliusz-t

The tools allows to automatically detect (and fix) errors and style issues, so I suggest adding:

  • black for consistent code formatting,
  • isort for standardized import sorting,
  • ruff for linting (error checking, style enforcement, etc.).

This will improve the consistency and readability of code.

Tasks:

  1. Add black, isort, and ruff as development dependencies.
  2. Configure them via pyproject.toml.
  3. Describe usage in README.
  4. Integrate checks into the CI pipeline.

Activity

  1. juliusz-t commented on Apr 23, 2025

    @juliusz-t
    Author

    I've uploaded the tooling effect in #571. For now it's just black and isort.
    I'm currently working on satisfying all the warnings from ruff, but it will need more intrusive refactoring.

  2. juliusz-t commented on Apr 23, 2025

    @juliusz-t
    Author

    In #569 a merge roadmap is proposed in terms of code quality (type hints and test coverage) and asyncio support. I will be happy to help you complete these two tasks. Could you evaluate the idea of ​​adding these tools in context of existing Pull Requests?

  3. acolomb commented on Apr 23, 2025

    @acolomb
    Member

    Please refrain from big "this fixes it all and refactors many things at the same time" pull requests. They are almost impossible to review and give little benefit for the time invested.

    As with typing, I'm totally fine with adding the tool configuration, though we shouldn't have to specify many non-default options. Then anyone can run them locally or on the CI and send in smaller, self-contained pulls fixing individual (classes of) errors / warnings for a tool. When it's finally ready to run without errors, the linters can be configured as a mandatory check in the CI. Please be careful with functional changes / refactoring just because of some linter message. Plain reformatting usually has the lowest benefit / cost ratio when it comes to review time, and I do think thorough reviews are good practice for a stable library.

    Hope you're okay with that approach, as I think it's the only way to get some serious review during the process.

    As for current development practice, I'm using mainly flake8 and have already pushed some smaller tidying up steps last year based on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions