Implement pre-commit hooks.

[owenlittlejohns]

Description

This PR begins the process of applying automated checking to all commits via pre-commit hooks. Currently it checks a small number of things:

• Trailing whitespace
• Blank lines at the end of the file.
• Valid JSON and YAML syntax.
• ruff linting.
• black code formatting

Why haven't I added mypy? So far all these checks have left the service code untouched. I think we should totally add both mypy, but just wanted to get the ball rolling here.

Jira Issue ID

N/A - this is an IP-ish bit of fun.

Local Test Steps

• Pull this branch.
• Follow the new instructions in the README to install pre-commit.
• Make some minor change, use git add then git commit. You should see the checks all run when you are trying to use git commit.

PR Acceptance Checklist

• Jira ticket acceptance criteria met.
• CHANGELOG.md updated to include high level summary of PR changes.
• VERSION updated if publishing a release.
• Tests added/updated and passing. (Well, the hooks are all passing, but that's not quite the same thing)
• Documentation updated (if needed).

[owenlittlejohns]

Oh, shoot. You already did this! Gaaah. Are you fine with just black instead of darker? Do you have a preference. Sorry to miss this!

[flamingbear]

From what I can tell when black-jupyter pre-commit runs, it will clean up an entire file. That could lead to a lot of git blames on unrelated changes.

I'm all for blacking these up, but should we consider including a full black commit on each repo that is excluded from git blame?

Something like this https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html#avoiding-ruining-git-blame

[owenlittlejohns]

I like this approach - thanks for talking through it with me on Tuesday. Here's my plan:

• I'll preemptively squash the current commits into a single one (because Squash and Merge isn't an option here). I know it's a bit bleugh to force push once stuff is in PR, but I think this time makes sense, where the later commits can't be squashed.
• I'll use black over all Python files (including test files). This will be it's own commit, for clarity.
• Then I'll add the secondary commit to ignore the black commit when using git blame (this is really cool by the way).
• Then I'll push up and we'll be set. 🤞

Other things:

• I feel like if there is any change in the service code, we probably should have an associated patch release, because even though the code should be unchanged functionally, I feel like we need to test this in isolation. Does this sound reasonable, or am I just being paranoid?
• Later work should, in the near future, add these checks to CI/CD, as we discussed at some point in the last couple of days.
• I'll try to prioritise HyBIG, because I think that's the repository where you'll be working next.

Does that all sound good?

[flamingbear]

That all sounds great to me. I was trying to get the black checks into the workflows but with internet and planning needs, I couldn't do it. Def want to do that next. I may sneak it in next time I work on any of these projects.

I think that plan is fine as long as you don't squash merge this PR.

Release question? IDK either way, I would do it because I'm lazy and there are no code changes, but I don't mind having one.

Actually we're changing code, even if it's just black formatting. So a patch is warranted.

[flamingbear]

We talked about this later and you did a patch release.

[owenlittlejohns]

Please check this commit hash matches the one for that implements black across the whole repo. I'm super paranoid I've got the wrong one!

[owenlittlejohns]

Just preserving this here:

There are incompatibilities between black and pycodestyle. A future goal is to make the same black and ruff checks run in the CI/CD. When we do that, I think we should nix the pylint and pycodestyle checks in favour of black and ruff.

[flamingbear]

This looks great to me. I'm excited

[flamingbear]

You don't want to commit?

[flamingbear]

You didn't get to see this.

[flamingbear]

That all sounds great to me. I was trying to get the black checks into the workflows but with internet and planning needs, I couldn't do it. Def want to do that next. I may sneak it in next time I work on any of these projects.

I think that plan is fine as long as you don't squash merge this PR.

Release question? IDK either way, I would do it because I'm lazy and there are no code changes, but I don't mind having one.

Actually we're changing code, even if it's just black formatting. So a patch is warranted.

[flamingbear]

We talked about this later and you did a patch release.

[flamingbear]

I hate black here. I wonder if it has a way to be skipped?
yes thanks stack overflow.

        # fmt: off
        palette_sequence = [
            255, 0, 0, 255,
            0, 255, 0, 255,
            0, 0, 255, 255,
            225, 100, 25, 25,
            0, 0, 0, 0
        ]
        # fmt: on

I would like that please.

[flamingbear]

I did it myself