Skip to content

Formatting with black and isort #189

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
+2,072 −1,024
Draft

Formatting with black and isort #189

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5408a0e
Formatted with black
max-models Oct 27, 2025
9151d5b
Formatted imports with isort
max-models Oct 27, 2025
a784433
Added static analysis workflow
max-models Oct 27, 2025
3815c71
Added .pre-commit-config.yaml with black and isort
max-models Nov 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions .github/workflows/static_analysis.yml
View file
Open in desktop
Copy link
Member

@gnikit gnikit Nov 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this CI workflow can largely be discarded in favour of pre-commit CI. I would only have to enable the webhook in the Settings and make it a mandatory check for the branch ruleset.
(Some others mentioned pre-commit in the discussion). Generally, it's a good idea to define your linting, formating, etc. in one place and then have pre-commit hooks locally and on the CI use them.
Less maintenance work, overall.

Copy link
Author

@max-models max-models Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hear you, it's a preference I guess. I prefer to avoid pre-commit hooks because they sometimes just gets in the way. Also, I tend to not always have them activated, and I see the same tendency among many others. As soon as they cause a moment of annoyance, people turn them off and then the formatting goes out the window. I feel like it's simpler to just let the developers choose themselves at which stage they would like to do the formatting. The pre-commit config file is there for anyone to activate if they would like, isn't that enough?

Copy link
Member

@gnikit gnikit Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

people can do as they wish on their machines, having a pre-commit yaml config does not change that.
The yaml config is what is read from the pre-commit.ci which will then automatically run the checks on GitHub.

Copy link
Author

@max-models max-models Nov 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok sorry I see what you mean now, I didn't know this was possible. I can update the CI.

Copy link
Member

@gnikit gnikit Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah so basically how this is done is:

  • repo configures isort, black, etc. in pyproject/setup.cgf or explicit config files for each tool
  • repo adds simple pre-commit-config.yaml see
  • repo/org admin enable the pre-commit.ci webhook
  • Optional: repo admin updates branch protection rules to include pre-commit webhook

Now every commit that is pushed on GitHub will be passed through isort/black/etc. and it will fail if any of the linters/formatter fail. You only have a single source of truth to worry about (the pre-commit config).

That being said for large projects, even locally, I find that it helps developing in an organised clean manner (abiding by linters, formatters, making atomic commits etc.), so I will almost certainly use pre-commit and run tests, when I commit and definitely before I push.

Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
name: Static analysis

on:
push:
branches:
- master
- devel
pull_request:
branches:
- master
- devel

defaults:
run:
shell: bash

jobs:

black:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- name: Checkout the code
uses: actions/checkout@v4

- name: Code formatting with black
run: |
pip install black "black[jupyter]"
black --check .
isort:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- name: Checkout the code
uses: actions/checkout@v4

- name: Code formatting with isort
run: |
pip install isort
isort --check .
15 changes: 15 additions & 0 deletions .pre-commit-config.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
repos:
# https://black.readthedocs.io/en/stable/integrations/source_version_control.html#
- repo: https://github.com/psf/black-pre-commit-mirror
rev: 25.11.0
hooks:
- id: black
files: \.py$

# https://pycqa.github.io/isort/docs/configuration/pre-commit.html
- repo: https://github.com/PyCQA/isort
rev: 7.0.0
hooks:
- id: isort
files: \.py$
args: [--profile=black]
2 changes: 1 addition & 1 deletion fprettify.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,5 +22,5 @@

from fprettify import run # pragma: no cover

if __name__ == '__main__': # pragma: no cover
if __name__ == "__main__": # pragma: no cover
run()
Loading