chore: remove unused import to pass flake8 on main

[p2edwards]

👀 Preview steps

• 🔴 [on main] recent (but not related) PR failing 'darker' flake8 linter test due to unused import — ❌ #5264
• 🟢 [on PR] i think this might fix it? — ✅ here

[p2edwards]

I'm starting to see how this happens

Currently the darker workflow compares:

• the pr's base commit in main
• the pr's merge commit, the results if this PR was merged right now

So if new commits appear in main, and then you push a new commit or trigger a workflow run again, you may get darker warnings on your PR that were introduced by unrelated changes in main that aren't in your 'branch' (and possibly didn't appear in CI for those PR's either).

Ways to make the signal clearer

Option 1: Compare latest main and the merge ref

Run linter on merged result, comparing:

• the latest HEAD of main ( ✏️ see ken muse's blog post for how to get this)
• the pr's merge commit (main after merge)
• Pros/cons:
  • 👍 If merging your PR would introduce linter warnings in main (at time of workflow run), you'll see those warnings.
  • ❕ You might see warnings in CI that you can't see locally unless you merge main or rebase your branch
  • ❔ If new commits appear in main after your CI run and they modify some of the same files, you could merge and still introduce a linter error somehow (rare, and likely you would get a mere problem anyway). So if it's been a while since your CI was run, it may be a good idea to manually re-trigger before merging.

Option 2: Compare PR base and head refs

Run linter just on the PR branch (before merge), comparing:

• the pr's base commit (${{ github.event.pull_request.base.sha }})
• the pr's head commit ( ✏️ make actions/checkout to use ${{ github.event.pull_request.head.sha }} )
• Pros/cons:
  • ❔ Results of tests confirm what you'd see locally
  • ❕ If the "merged" result triggers linter errors, you wouldn't see them on your branch's CI run. (Trivial example: let's say there's a fake rule that all files must be 8 lines or fewer. Another branch adds 6 lines for a total of 7, yours adds 2 lines for a total of 3. Neither PR CI triggers fake linter, but when both are merged without conflict, linter rule is broken). So if the goal is to prevent surprises in main after merging, this wouldn't fully do it.

Option 3: A combo of both

• Failing on one or the other indicates an issue and a good next step
• For tests that are cheap, this can help spot the source.
  • merge test is more important overall
  • a passing pr test with a failing merge test tells you you need to merge main