[pre-commit.ci] pre-commit autoupdate

[pre-commit-ci[bot]]

updates:

• github.com/PyCQA/flake8: 6.1.0 → 7.0.0
• github.com/psf/black: 23.12.0 → 24.2.0

[Zeitsperre]

What's stopping this from being changed to true?

[willingc]

@Zeitsperre Ultimately, this would be @lwasser's call. There are two schools of thought around using the pre-commit autofix in CI:

• Setting autofix to True. Benefits: Fix done automatically which is helpful if the PR needs no other modification. Con: If further changes are needed, contributors need to be aware that they need to pull the bot's changes and likely force push additional changes later.
• Setting autofix to False. Benefits: Fixes unrelated to the actual PR are not made. For example, autofix of this PR would fix files unrelated to bumping the versions of black and flake8. Depending on the fixes made this leads to an untidy history and less encapsulation of changes. Also, contributors are not suprised that the bot has changed their PR. Cons: It will not fix small issues like whitespace directly related to the PR change which would be useful.

I don't think there is a right or wrong approach, but merely a tradeoff on what is most important to the project.

[lwasser]

oh yes thank you @willingc you articulated that well. @Zeitsperre i worry that for new contributors, having to force push can be scary and also if you don't know about force pushing it will be confusing as can having to pull down changes without knowing they have been made (if they are not watching the pr closely).

this way we can just run the bot right before we merge as maintainers and contribs don't have to worry about linting / code format.

[Zeitsperre]

@willingc Thanks for the rundown! I've run into that same situation in other projects. The solution I've landed on is to set things to True by default and have the Pull Request Template and Contributing documentation mention that they should install pre-commit when making changes.

One other thing that could help justify the False setting is actually a security issue associated with pre-commit: first-time contributors who are otherwise blocked from running GitHub Workflows by default can exploit pre-commit to push changes that intentionally break the linting; This would then trigger the pre-commit.ci to push changes and then trigger the workflows anyway. I can imagine a bad actor using that to try and leak some private tokens from an insecurely-written workflow.

It's something I discovered by accident a few months back. Perhaps I should disclose that to the developer.

EDIT: it's been mentioned before: https://github.com/pre-commit-ci/issues/issues/195

[willingc]

@Zeitsperre Interesting point about security (and thanks for the link to the issue on pre-commit) and one that I hadn't thought about but is definitely a possibility.

Given the current size of pyOpenSci and activity, I think for now that leaving as False makes sense.

I will fix the formatting issues in another PR.

[willingc]

95 and #96 replace this PR, and I am closing this auto-generated PR.