Skip to content
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.

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

top: Pin black version. #749

Closed
wants to merge 1 commit into from
Closed

Conversation

jimmo
Copy link
Member

@jimmo jimmo commented Oct 17, 2023

This replaces the codeformat.py script with just running black directly, both from GitHub CI and from pre-commit, same as how we do ruff.

This allows us to avoid needing to use the system black version for pre-commit, and lets us pin the same version for both.

pyproject.toml is now used for configuration.

The old codeformat.py is still kept (but now just runs black directly).

This work was funded through GitHub Sponsors.

This replaces the codeformat.py script with just running black directly,
both from GitHub CI and from pre-commit, same as how we do `ruff`.

This allows us to avoid needing to use the system black version for
pre-commit, and lets us pin the same version for both.

pyproject.toml is now used for configuration.

The old codeformat.py is still kept (but now just runs black directly).

This work was funded through GitHub Sponsors.

Signed-off-by: Jim Mussared <[email protected]>
Copy link
Contributor

@projectgus projectgus left a comment

Choose a reason for hiding this comment

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

Yay pinned tool versions!

- name: Check code formatting
run: git diff --exit-code
- uses: actions/checkout@v4
- run: pip install --user black==23.7.0
Copy link
Contributor

@projectgus projectgus Oct 18, 2023

Choose a reason for hiding this comment

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

Maybe I have too much DRY brainworms, but could we add a [project.optional-dependencies] section to pyproject.toml for these versions? (I/we could also do this in a follow-up PR for this & ruff together, if that's easier.)

The main advantage is that we could then tell developers to install the linter tools from there (and Python developers will instinctively go there anyway). This means they will have matching versions in any IDE integrations, pylsp, etc and [hopefully] won't run into the situation of the pre-commit hook re-formatting (or re-linting) code that their IDE had already formatted or linted slightly differently. (This happens to me sometimes, at least!)

(AFAIK the version still needs to be duplicated in two places even then, because pre-commit maintains its own sandboxes and reads those versions from .pre-commit-config.yaml. No way around that, from what I can see.)

@dpgeorge
Copy link
Member

Superseded by #759.

@dpgeorge dpgeorge closed this Dec 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants