Replies: 1 comment 1 reply
-
@finswimmer, would you be open to pulling this repo into the python-poetry organization, potentially renaming to something more like 'poetry-precommit', and deprecating the in-repo hook definition? I think this is the best resolution available because, to be blunt, I don't think there's any point in looking for a compromise on the pre-commit side of things. I would be willing and able to get involved to help maintain this project. (For example, moving from |
Beta Was this translation helpful? Give feedback.
-
Hey,
in #2511 I was responsible for adding direct
pre-commit
support to poetry and maintained a mirror repo for usage of poetry with pre-commit until the 1.2 release.Issue
With the 1.2 releases arose an issue with pre-commit's autoupdate command, which downgrades 1.2 releases to the latest 1.2 rc-release. I personally just found out about this issue, but it was already discussed in pre-commit #2507 and #6990 and is mentioned in the docs.
The bottom line is, that poetry's branching model is incompatible with pre-commit's approach to determine the latest release of a repo.
Solution
To solve this issue I am planning to reactive the aforementioned mirror repo (no ETA but hope I will get to that soon). This repo will then get a 2 step GHA workflow:
This means that patch releases for earlier releases will not be added. Reason for this is simple. pre-commit takes the latest tag from the default branch as the latest release. If I would add 1.1.x after 1.2.x then everyone would downgrade from 1.2 to 1.1 again, which is undesired.
.pre-commit-hooks.yaml
file of that release with the repo's own version of it. If there is a diff, update the repo's version.With this workflow the mirror repo should have almost 0 maintenance needs and be up-to-date.
pre-commit's autoupdate should then work again (if one uses the mirror stead of the poerty repo).
The downside that patch releases for older minor and major releases will not be supported is IMO no big deal, as poetry has a
.pre-commit-hooks.yaml
file included for those older releases and one can then pin to those releases from the poetry repo directly instead of the mirror.Proposal
Because I myself need this solution for my own projects, I will most certainly implement this regardless. If someone has a better solution, I would probably opt for that then instead.
My proposal is twofold:
python-poetry
organization. In this case I guess a renaming of the repo would be good to something likepoetry-pre-commit-hooks
.I would then also propose to outsource the
.pre-commit-hooks.yaml
file completely frompython-poetry/potry
repo into this new one, so that there is a good separation of concerns. Only downside to this is, that then patch releases for older minor/major version really would loose support for pre-commit.I am open for discussion :)
EDIT: I reactivated the repo and the current 1.2.2 releaese is there too. The workflow runs every night and worked to create the 1.2.2 releaes, but seems buggy if there is no new release. I will need to fix that, but the repo should nontheless be usable for pre-commit.
EDIT2: Workflows is fixed and running. Happy using :)
Beta Was this translation helpful? Give feedback.
All reactions