Definitely agree with both of you, will be trying this out myself as well. Definitely looking forward to seeing alternatives in the space! -- Regards, Aritra Basu
On Thu, 7 Aug 2025, 9:24 pm Jarek Potiuk, <ja...@potiuk.com> wrote: > > Pre-commit is great for its stability but is really failing in terms of > innovation, the project itself does not allow any discussion of using new > standards. > > Had my fair share of those discussions in the past and I quite agree. > There is huge difference between "stability" and "stagnation/stubbornness". > > On Thu, Aug 7, 2025 at 5:39 PM Damian Shaw <ds...@striketechnologies.com> > wrote: > > > I just want to say I am very excited to see innovation in this space! > > > > Pre-commit is great for its stability but is really failing in terms of > > innovation, the project itself does not allow any discussion of using new > > standards. > > > > I will be testing it out in my own environments and then promoting it > > widely. > > > > Damian > > > > -----Original Message----- > > From: Jarek Potiuk <ja...@potiuk.com> > > Sent: Thursday, August 7, 2025 10:01 AM > > To: dev@airflow.apache.org > > Subject: [DISCUSS] Upcoming pre-commit -> prefligit change > > > > Hello everyone, > > > > Early warning about upcoming pre-commit/prefligit change...... > > > > Together with Ash and creator of the prefligit: > > https://github.com/j178/prefligit - we are testing and helping to close > > the gaps between prefligit and pre-commit (and later we hope we will be > > able to improve our prefligit integrations with upcoming monorepo support > > especially - which would help us to modularise our pre-fligits (that's > the > > name we will likely start using ;) .. > > > > It seems we are very close so I wanted to make a short "upcoming change" > > note so that you are aware: > > > > * *breeze static-checks *will hopefully be gone and replaced by > > `prefligit` command - the author of prefligit is super-receptive to > things > > like `--last-commit` flags and autocomplete including our hook names - > so I > > think we will be able to remove the whole `static-check` machinery from > > breeze that added what we needed > > > > * *prefiligit* uses *uv* by default - no more `uv tool install pre-commit > > --with pre-commit-uv` needed to enable it (again the author of prefligit > is > > way more receptive to the needs of users and there will be no need to > patch > > pre-commit to use `uv` (which effectively `--with pre-commit-uv` does) > > > > That's another step of simplifying our dev env setup where existing > > tooling finally catches up with what we need and we can remove some of > our > > custom > > (breeze) code that does it (which makes me super happy). > > > > More about it soon, when we get a new release of prefligit that will > solve > > all the remaining (small) issues and have auto-complete merged > (contributed > > by someone based on our issue > https://github.com/j178/prefligit/pull/380 > > :). > > > > If there are any concerns or doubts - feel free to raise them :) > > > > J. > > ________________________________ > > Strike Technologies, LLC (“Strike”) is part of the GTS family of > > companies. Strike is a technology solutions provider, and is not a broker > > or dealer and does not transact any securities related business directly > > whatsoever. This communication is the property of Strike and its > > affiliates, and does not constitute an offer to sell or the solicitation > of > > an offer to buy any security in any jurisdiction. It is intended only for > > the person to whom it is addressed and may contain information that is > > privileged, confidential, or otherwise protected from disclosure. > > Distribution or copying of this communication, or the information > contained > > herein, by anyone other than the intended recipient is prohibited. If you > > have received this communication in error, please immediately notify > Strike > > at i...@striketechnologies.com, and delete and destroy any copies > hereof. > > ________________________________ > > > > CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments > > are intended solely for the addressee. This transmission is covered by > the > > Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The > > information contained in this transmission is confidential in nature and > > protected from further use or disclosure under U.S. Pub. L. 106-102, 113 > > U.S. Stat. 1338 (1999), and may be subject to attorney-client or other > > legal privilege. Your use or disclosure of this information for any > purpose > > other than that intended by its transmittal is strictly prohibited, and > may > > subject you to fines and/or penalties under federal and state law. If you > > are not the intended recipient of this transmission, please DESTROY ALL > > COPIES RECEIVED and confirm destruction to the sender via return > > transmittal. > > >
