In order to avoid running into issues with versions of black that
are not updated unless the hook is installed / updated (which causes
differences in formatting), this pins black in the hook
definition.
I'm not sure if it wouldn't be better to do that in each project's
.pre-commit-config.yaml (as it is recommended by the author of
pre-commit), but updating of additional_dependencies is a unsolved
issue: pre-commit supports multiple languages / package managers,
and parsing whatever the package manager accepts is a hard
problem. And according to the issue tracker, it will probably never
implemented. Which is why auto-updating the pinned version would
require a separate hook / CI job to update.
In this PR we go with pinning black in the hook definition, but I
could just as well imagine running a hook that extracts the version of
the black hook and updates the pinned version with it.
[x] Closes #122
[x] Passes pre-commit run --all-files
[ ] User visible changes (including notable bug fixes) are documented in changelog.rst
In order to avoid running into issues with versions of
black
that are not updated unless the hook is installed / updated (which causes differences in formatting), this pinsblack
in the hook definition.I'm not sure if it wouldn't be better to do that in each project's
.pre-commit-config.yaml
(as it is recommended by the author ofpre-commit
), but updating ofadditional_dependencies
is a unsolved issue:pre-commit
supports multiple languages / package managers, and parsing whatever the package manager accepts is a hard problem. And according to the issue tracker, it will probably never implemented. Which is why auto-updating the pinned version would require a separate hook / CI job to update.In this PR we go with pinning
black
in the hook definition, but I could just as well imagine running a hook that extracts the version of theblack
hook and updates the pinned version with it.pre-commit run --all-files
changelog.rst