hi

[asottile]

the best time for collaboration probably would have been when starting the project but I guess the second best time is now!

the slated long-term plan for pre-commit is to replace the python implementation with rust -- I've been slowly working towards that over the last couple of years but I've been busy and progress has been slow. I figure we can probably accelerate that if you'd like to work together on accomplishing it

there's also the tricky task of compatibility and migration (which I've fortunately thought a lot about and will hopefully make the transition smoother!) -- the main compatibility issues is going to be around regular expressions, language: pygrep, and ultimately bootstrapping python where missing for language: python (though I think uv will likely take that responsibility at some point) -- happy to talk more on this though as it's kinda the hardest part of making such a shift successful

can also help with the planned direction I'm going for with languages in general -- as that's going to break a lot of what isn't yet implemented here (or there) since the structure and internals are likely to change a lot there (goal being to divorce the installations, repositories, and languages as they're really three separate entities currently represented as one (maybe 1.5 if we're being honest))

an aside -- the repository in the current state violates several copyrights and licenses. I intentionally chose to release my code under MIT to make it very simple to abide by the license (simply distribute a copy of the license in derivative works) but unfortunately your current implementation reads as a plagiarism -- fortunately an easy fix to include the licenses of your copied work!

[j178]

I'm thrilled to see you, @asottile!

I apologize for the copyright violation regarding pre-commit. I must admit that I essentially translated the original Python implementation into this project. I've now added a copyright notice for pre-commit to the LICENSE in #74. Thank you so much for your outstanding work on pre-commit!

I started this project purely to practice Rust and was completely unaware of the existence of https://github.com/pre-commit/pre-commit-rs, which has been around for two years! I never intended for this project to become widely known, so I didn't reach out for collaboration—especially since my Rust skills are quite basic and I wasn't sure how far this project would go.

I'm truly honored by your invitation to collaborate! I believe the ideal home for this project is https://github.com/pre-commit/pre-commit-rs. Do you have any specific plans for moving forward? Since I wasn't aware of https://github.com/pre-commit/pre-commit-rs, my implementation took a slightly different path. How do you find the current implementation? Would you prefer a merge, or should we develop anew from the ground up?

But there are reasons this project should continue. I have ideas that might differ from yours regarding implementations or feature additions. Initially, I envisioned this project as a unique dialect of the original pre-commit, not a replacement. I might keep some distinct features here, as the original pre-commit is so widely used, and adding features or making breaking changes is challenging. This way, users can choose whichever suits them best.

What do you think? Thanks again for reaching out—I really appreciate it!

[asottile]

I'm truly honored by your invitation to collaborate! I believe the ideal home for this project is https://github.com/pre-commit/pre-commit-rs. Do you have any specific plans for moving forward? Since I wasn't aware of https://github.com/pre-commit/pre-commit-rs, my implementation took a slightly different path. How do you find the current implementation? Would you prefer a merge, or should we develop anew from the ground up?

I haven't had time to look over much of this code yet -- though the few files I've glanced at look like they were straight ported by chatgpt? given that I think I'd prefer to continue in the approach I was going with -- which is carefully porting a piece of functionality at a time until the rest is built out -- and then working on the compatibility / transition plan (tool for testing existing configuration for regex compatibility, "deprecating" pygrep for rsgrep (doesn't exist yet), etc.)

But there are reasons this project should continue. I have ideas that might differ from yours regarding implementations or feature additions. Initially, I envisioned this project as a unique dialect of the original pre-commit, not a replacement. I might keep some distinct features here, as the original pre-commit is so widely used, and adding features or making breaking changes is challenging. This way, users can choose whichever suits them best.

I was a little worried you'd say this. I hope you understand the optics of what you've built so far looks like a hostile fork -- and is unethical to lift the code as you've done. the "not a replacement" at the very least seems disingenuous given your README uses exactly the word replacement.

ideally this wouldn't continue. two separate divergent implementations is going to create a rift in users and add undue compatibility / complexity pains (for both parties!).

I totally get wanting to learn rust and try out cool things but I would strongly encourage you to build your own project instead of ripping off mine :) and while my LICENSE intentionally does not forbid you to do such things I'd encourage you think think about them from an ethical perspective.

and ignoring all of that if you want to continue divergently please change the name to reduce as much confusion as possible (pre-commit's name already sucks enough -- I'd hate for you to carry that too!)

[jbvsmo]

I would also recommend this project to distance itself from pre-commit as much as possible. Just not for the above reasons...

Next time he should use GPL if he feels the need to bully people

[potiuk]

Just a comment - we love prek at Apache Airflow and we are going to migrate very very soon. We've been collaborating with @j178 over the last weeks and i think a number of improvements vs. the original pre-commit that we asked for years and got implemented in a few hours or so is staggering. PR to implement it is up and I keep on rebasing until the last small missing pieces are implemented and all wrinkles are ironed out. apache/airflow#54258

All thing that we've asked for and were either straight rejected by @asottile or had absolutely unreasonable expectations already makes prek far better choice. That includes as simple things as autocomplete, or running multiple hooks at single run command, not mentioning the vision of supporting projects that have multiple distributions in monorepo.

Luckily almost no-one in Airflow used pre-commit directly - we had to wrap it in our own breeze static checks in order to make a number of things work for us, but with prek - I am definitely pushing for removing all ~1600 lines of code we had to wrap it and recommend our contributors not only to install pre-commit but also use if on a daily basis. We are going to remove our wrapper. After few previous attempts of contributing to pre-commit or raising issues an being treated with harsh reactions, very strong opinions of @asottile that were alongside "I do not even listen to some of my important users who base their whole development on my concept, I have my ideas and I don't care about their needs as they are outliers" kind of answers, we even stopped asking and implemented all we wanted in the wrapper. Now we can just straight drop it.

This is how "Switch pre-commit to prek" PR stats look like

That single screenshot is a statement on its own.

The preflight name had the typosquatting potential as discussed in this discussion where I started to discuss the potential change https://lists.apache.org/thread/mb73g4rz56n5l0gjyzm9jzolnkkc6o5c and the almost instant reaction of @j178 and making tough choice is clearly a sign that he listens to his users concerns and responds, but also from all the discussions I know he has a firm vision that he follows and is not easily taken off-track (with the few discusisons on issues we had I not only made some proposal but learned a thing or two and I think the collaboration here is great.

With Airlfow being one of the strong adopters of the 'pre-commit' initial concept with 170+ precommits that are literally driving our development efforts in multiple ways, we are thrilled with prek.

And we do not see as a hostile fork - not even close. With MIT licence and very clear atribution and thanks to original pre-commit project, prek name, @j178 had done everything right here. It's just a healthy project that is not shy of the legacy of pre-commit original ideas, project that chose a different path of evolution with author who has different vision of collaboration and cooperation with the users and as I see it shows, "smart", "assertive" approach but also shows that the reason for prek is to serve those who use them and helps to solve their issues. With years of pre-commit stagnation and lack of listening to the users, that was inevitable, and so far @j178 executes it brillantly - as far as someone who is the "dev env" lead of the team that manages development environment of Apache Airflow - one of the biggest users of pre-commit idea among open source projects.

Thanks @asottile for coining the concept, thanks for all the years of actually releasing pre-commit and making it possible to use it, but clearly the time had come that there are other, better ways and pre-commit is no longer good for many, there are better alternatives like prek. Time to move on.

And thanks to @j178 for all the ideas and hard work and cooperation - we are looking forward to what's next. It will help us to bring airflow to a new world for us - we already have 100+ distributions in our monorepo, we introduce golang and few other languages and having a great, supportive tool in the form of prek for that will be a life-saver.