#precommit — Public Fediverse posts

@15r10nk nice ❣️ I added it to #Python #awesomelist #precommit https://github.com/cleder/awesome-pre-commit-hooks

@15r10nk nice ❣️ I added it to #Python #awesomelist #precommit https://github.com/cleder/awesome-pre-commit-hooks

Usually a quick chore, but with the #ruff feature update, an unexpected ton of work…

#django #python #precommit

Usually a quick chore, but with the #ruff feature update, an unexpected ton of work…

#django #python #precommit

@holl Do you version control your files?

If so the there are two pre-commit hooks available...

https://github.com/vdmitriyev/latex-git-hooks
https://github.com/jonasbb/pre-commit-latex-hooks

(I don't write in LaTeX these days but am a big fan of pre-commit).

#latex #precommit

@holl Do you version control your files?

If so the there are two pre-commit hooks available...

https://github.com/vdmitriyev/latex-git-hooks
https://github.com/jonasbb/pre-commit-latex-hooks

(I don't write in LaTeX these days but am a big fan of pre-commit).

#latex #precommit

@Python4DataScience Oh interesting, I did not know prek had those extra features... I'll have to look into that for work.

#Python #PreCommit #prek

@Python4DataScience Oh interesting, I did not know prek had those extra features... I'll have to look into that for work.

#Python #PreCommit #prek

The #awesome #precommit #awesomelist now has the following:

Languages: cpp, css, docker, env, go, groovy, img, js, kt, lua, make, md, nb, proto, py, r, rb, ru, sh, sql, swift, tf, toml, ts, yaml
Frameworks: Ansible, django, git, k8s, react, sphinx

Unique repos: 87

https://github.com/cleder/awesome-pre-commit-hooks

The #awesome #precommit #awesomelist now has the following:

Languages: cpp, css, docker, env, go, groovy, img, js, kt, lua, make, md, nb, proto, py, r, rb, ru, sh, sql, swift, tf, toml, ts, yaml
Frameworks: Ansible, django, git, k8s, react, sphinx

Unique repos: 87

https://github.com/cleder/awesome-pre-commit-hooks

The #awesomelist of #awesome #precommit and #prek hooks now has 82 unique repos.

Languages: cpp, css, docker, go, img, js, kt, make, md, nb, proto, py, r, rb, ru, sh, sql, swift, tf, toml, ts, yaml

Frameworks: Ansible, django, git, k8s, react, sphinx

https://github.com/cleder/awesome-pre-commit-hooks

The #awesomelist of #awesome #precommit and #prek hooks now has 82 unique repos.

Languages: cpp, css, docker, go, img, js, kt, make, md, nb, proto, py, r, rb, ru, sh, sql, swift, tf, toml, ts, yaml

Frameworks: Ansible, django, git, k8s, react, sphinx

https://github.com/cleder/awesome-pre-commit-hooks

reLint 3.5 is out!
Special thanks to @BatmanAoD

https://github.com/codingjoe/relint

#python #javascript #openSource #regex #linter #precommit #skills

reLint 3.5 is out!
Special thanks to @BatmanAoD

https://github.com/codingjoe/relint

#python #javascript #openSource #regex #linter #precommit #skills

RE: https://hachyderm.io/@cleder/116823890089323460

#prek and #precommit go #🦧️💩️ over insecure code produced by #AI #LLM
- would have been the clickbaity headline 😁️ @calvin

RE: https://hachyderm.io/@cleder/116823890089323460

#prek and #precommit go #🦧️💩️ over insecure code produced by #AI #LLM
- would have been the clickbaity headline 😁️ @calvin

An unexpected bonus when you generate your `pre-commit-config.yaml` with `ps-init --detect` is that from the installed hooks: detect-secrets, proselint, codespell, commitizen, typos, cargo-check, clippy, fmt, gitleaks, yamlfmt, gitlint, pre-commit-sort, ryl, rumdl-fmt, semgrep, doctoc, talisman-commit, trufflehog, zizmor

That when prompted "create github actions including unittests (with coverage)", agents write for e.g. a fresh #rust project

```
.github/workflows
├── ci.yml
├── compat.yml
├── lint.yml
├── release.yml
└── security.yml
```

and configure all the lint and security github actions -- which in turn will make the commit go 🐒 💩 , the security hooks reporting a lot of 'concerns' about the insecure configuration the LLM wrote, resulting in a feedback loop to harden them ;-)

#prek #precommit #python
@pythonbytes @calvinhp
https://github.com/cleder/gpc-init/

An unexpected bonus when you generate your `pre-commit-config.yaml` with `ps-init --detect` is that from the installed hooks: detect-secrets, proselint, codespell, commitizen, typos, cargo-check, clippy, fmt, gitleaks, yamlfmt, gitlint, pre-commit-sort, ryl, rumdl-fmt, semgrep, doctoc, talisman-commit, trufflehog, zizmor

That when prompted "create github actions including unittests (with coverage)", agents write for e.g. a fresh #rust project

```
.github/workflows
├── ci.yml
├── compat.yml
├── lint.yml
├── release.yml
└── security.yml
```

and configure all the lint and security github actions -- which in turn will make the commit go 🐒 💩 , the security hooks reporting a lot of 'concerns' about the insecure configuration the LLM wrote, resulting in a feedback loop to harden them ;-)

#prek #precommit #python
@pythonbytes @calvinhp
https://github.com/cleder/gpc-init/

You’re starting a new project, you’ve got your repo initialized, and now comes the tedious part—setting up the quality gates.

You know you need pre-commit (or the newer #prek to keep your code clean, but you end up hunting through your older repositories to find the "best" `.pre-commit-config.yaml` to copy and paste.

It’s a chore that breaks your flow before you’ve even written a line of code.

@pythonbytes @mkennedy @calvinhp
#precommit
https://github.com/cleder/gpc-init

You’re starting a new project, you’ve got your repo initialized, and now comes the tedious part—setting up the quality gates.

You know you need pre-commit (or the newer #prek to keep your code clean, but you end up hunting through your older repositories to find the "best" `.pre-commit-config.yaml` to copy and paste.

It’s a chore that breaks your flow before you’ve even written a line of code.

@pythonbytes @mkennedy @calvinhp
#precommit
https://github.com/cleder/gpc-init

@veit Nice let me add that to my #precommit and https://github.com/cleder/gpc-init

@veit Nice let me add that to my #precommit and https://github.com/cleder/gpc-init

RE: https://hachyderm.io/@cleder/116807441810538608

The #awesomelist for the #awesome #precommit and #prek are now at 58 unique repos.

Languages: docker, go, img, js, md, nb, py, r, ru, sh, sql, tf, toml, ts, yaml

Frameworks: Django, git, k8s, react, sphinx

Thank you ❣️

https://github.com/cleder/awesome-pre-commit-hooks

RE: https://hachyderm.io/@cleder/116807441810538608

The #awesomelist for the #awesome #precommit and #prek are now at 58 unique repos.

Languages: docker, go, img, js, md, nb, py, r, ru, sh, sql, tf, toml, ts, yaml

Frameworks: Django, git, k8s, react, sphinx

Thank you ❣️

https://github.com/cleder/awesome-pre-commit-hooks

@cleder Thanks, have just created a PR to add a few more.

#precommit #python #r #markdown #codespell

@cleder Thanks, have just created a PR to add a few more.

#precommit #python #r #markdown #codespell

RE: https://hachyderm.io/@cleder/116796446972749174

My #awesomelist for #precommit and #prek is now at 60 #awesome hooks. 🎉

Find linters, formatters, security scanners, code quality tools, and more in one place.

Contributions welcome! 🔧

Languages

docker, go, img, js, md, nb, py, ru, sh, sql, tf, toml, ts, yaml

Frameworks

bevy, django, git, k8s, react, sphinx

⭐ https://github.com/cleder/awesome-pre-commit-hooks

#Python #DevOps #OpenSource #DeveloperTools #CodeQuality

RE: https://hachyderm.io/@cleder/116796446972749174

My #awesomelist for #precommit and #prek is now at 60 #awesome hooks. 🎉

Find linters, formatters, security scanners, code quality tools, and more in one place.

Contributions welcome! 🔧

Languages

docker, go, img, js, md, nb, py, ru, sh, sql, tf, toml, ts, yaml

Frameworks

bevy, django, git, k8s, react, sphinx

⭐ https://github.com/cleder/awesome-pre-commit-hooks

#Python #DevOps #OpenSource #DeveloperTools #CodeQuality

The pre-commit ecosystem is huge, but discovering good hooks can be surprisingly difficult.

I've started **Awesome Pre-commit Hooks**, a curated list of #precommit and #prek hooks organised by language and framework.

Check it out and help grow it:

https://github.com/cleder/awesome-pre-commit-hooks

#Python #OpenSource #DevTools #CodeQuality #Automation

The pre-commit ecosystem is huge, but discovering good hooks can be surprisingly difficult.

I've started **Awesome Pre-commit Hooks**, a curated list of #precommit and #prek hooks organised by language and framework.

Check it out and help grow it:

https://github.com/cleder/awesome-pre-commit-hooks

#Python #OpenSource #DevTools #CodeQuality #Automation

I use pre-commit (and now are beginning to migrate to prek) extensively in all my projects (work and hobby), and create a lot of repositories (every other month or so, enough for this to be a pain point, but not enough to have the workflow committed to my muscle memory).

Whenever I created a new repo, I had to cut and paste the .pre-commit-config.yaml into the new project, which requires remembering what other project has the most appropriate and up-to-date configuration.

Now I ditched the Copy-Paste Workflow: Scaffold Your Quality Tools with pc-init

#python #prek #precommit

https://dev.to/ldrscke/stop-copying-your-pre-commit-configyaml-241d

I use pre-commit (and now are beginning to migrate to prek) extensively in all my projects (work and hobby), and create a lot of repositories (every other month or so, enough for this to be a pain point, but not enough to have the workflow committed to my muscle memory).

Whenever I created a new repo, I had to cut and paste the .pre-commit-config.yaml into the new project, which requires remembering what other project has the most appropriate and up-to-date configuration.

Now I ditched the Copy-Paste Workflow: Scaffold Your Quality Tools with pc-init

#python #prek #precommit

https://dev.to/ldrscke/stop-copying-your-pre-commit-configyaml-241d

Not sure if this is useful to anyone other than me, but I made a TODO item linter that complains if the TODO items in your code don't have an owner and a reference to an issue so someone has a chance of addressing them in the future:

https://worktree.ca/taffer/todo-linter

Works with pre-commit: https://pre-commit.com

#todo #fixme #python #pre-commit #precommit #git

Not sure if this is useful to anyone other than me, but I made a TODO item linter that complains if the TODO items in your code don't have an owner and a reference to an issue so someone has a chance of addressing them in the future:

https://worktree.ca/taffer/todo-linter

Works with pre-commit: https://pre-commit.com

#todo #fixme #python #pre-commit #precommit #git

prek now supports cooldown in either user or project config:

https://github.com/j178/prek/releases/tag/v0.3.12

pre-commit closed and locked the feature request as one of many many duplicates, but I can't find any:

https://github.com/pre-commit/pre-commit/issues/3614

#PreCommit #prek #cooldown

prek now supports cooldown in either user or project config:

https://github.com/j178/prek/releases/tag/v0.3.12

pre-commit closed and locked the feature request as one of many many duplicates, but I can't find any:

https://github.com/pre-commit/pre-commit/issues/3614

#PreCommit #prek #cooldown

To aid #developers using #AI to disclose their prompts and make the #collaboration more obvious, we maintain a simple #tool that allows developers to collect all prompts and append them to commit messages:

https://github.com/pycalendar/ai-prompt-auto-commit

Projects using #Claude_code or #GitHubCopilot can automate the commit workflow using a #precommit #hook.

#generativeAI #pycal

I wanted to talk even more about dockerizing pre-commit for security gains - so I typed up a short blog post about how to achieve this.

Please feel invited to try it out and share back results ⬇️

https://overtag.dk/v2/blog/pre-commit-in-docker/

I'd also like to hear from people who aren't worried about pre-commit vulnerabilities and why ❓

#precommit #python

I wanted to talk even more about dockerizing pre-commit for security gains - so I typed up a short blog post about how to achieve this.

Please feel invited to try it out and share back results ⬇️

https://overtag.dk/v2/blog/pre-commit-in-docker/

I'd also like to hear from people who aren't worried about pre-commit vulnerabilities and why ❓

#precommit #python

A screenshot from running a dockerized pre-commit.

And here's the whole darn alias 🥳

```
$ which pre-commit
pre-commit: aliased to docker run -v "pre-commit-cache":/home/dockeruser/.cache -v "$(pwd)":/repo:rw -e PRECOMMITALIAS="$(alias pre-commit)" -e PGID="$(id -g)" -e PUID="$(id -u)" pre-commit:python3.14
```

Instructions on building and running it are in the repo ⬇️
https://codeberg.org/benjaoming/pre-commit-docker-alias

#precommit

A screenshot from running a dockerized pre-commit.

And here's the whole darn alias 🥳

```
$ which pre-commit
pre-commit: aliased to docker run -v "pre-commit-cache":/home/dockeruser/.cache -v "$(pwd)":/repo:rw -e PRECOMMITALIAS="$(alias pre-commit)" -e PGID="$(id -g)" -e PUID="$(id -u)" pre-commit:python3.14
```

Instructions on building and running it are in the repo ⬇️
https://codeberg.org/benjaoming/pre-commit-docker-alias

#precommit

Was contemplating if it makes sense to have a single image for ALL pre-commit needs and alias `pre-commit` to `docker run pre-commit -v "$(pwd)":/workdir:rw`

Oh and yes, this is inspired by all the supply chain stuff. If the alternative is that each pre-commit hook becomes its own Docker image, I'm afraid it'll be too slow.

Any experiences?

(edited: docker exec isn't possible with volumes)

#precommit

Was contemplating if it makes sense to have a single image for ALL pre-commit needs and alias `pre-commit` to `docker run pre-commit -v "$(pwd)":/workdir:rw`

Oh and yes, this is inspired by all the supply chain stuff. If the alternative is that each pre-commit hook becomes its own Docker image, I'm afraid it'll be too slow.

Any experiences?

(edited: docker exec isn't possible with volumes)

#precommit

My plan B is to look at running #PreCommit alternative #Prek https://prek.j178.dev/ on #Codeberg’s Woodpecker CI (where quicker installation and faster runtimes etc should pay off)

My plan B is to look at running #PreCommit alternative #Prek https://prek.j178.dev/ on #Codeberg’s Woodpecker CI (where quicker installation and faster runtimes etc should pay off)

Running the #PreCommit tool (for listing, enforcing coding style, etc) via the author’s CI service https://pre-commit.ci/ has excellent #GitHub integration - with the docs suggesting that other hosting sites might be supported at some point.

I’ve just asked directly about #Codeberg (and #ForgeJo generally) as I’d love to use it there too: https://github.com/pre-commit-ci/issues/issues/261

Running the #PreCommit tool (for listing, enforcing coding style, etc) via the author’s CI service https://pre-commit.ci/ has excellent #GitHub integration - with the docs suggesting that other hosting sites might be supported at some point.

I’ve just asked directly about #Codeberg (and #ForgeJo generally) as I’d love to use it there too: https://github.com/pre-commit-ci/issues/issues/261

At work we maintain a range of project templates for various languages such as #Python and #cpp we have been looking to migrate from #tox to #precommit and #uv but now #Astral the company behind uv and ruff has been acquired by OpenAI.

So everything is ready im just not sure anymore if we should, despite certain benefits its quite hard to ignore how many things are being ruined by corporate AI

If you are wondering about such a pre-commit + uv setup you can find it here: https://github.com/astron-rd/PACE/pull/50

Investigating the conversion between #tox and #pip enabled projects to #precommit and #UV

This investigation is almost done and will modernize our #cruft #cookiecutter Python template.

Not my post but worth reading...

pre-commit hooks are fundamentally broken

https://jyn.dev/pre-commit-hooks-are-fundamentally-broken/

Note that the pre-commit framework can also be used to manage pre-push and other hooks

#git #precommit #hooks

Not my post but worth reading...

pre-commit hooks are fundamentally broken

https://jyn.dev/pre-commit-hooks-are-fundamentally-broken/

Note that the pre-commit framework can also be used to manage pre-push and other hooks

#git #precommit #hooks

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HotTo

https://fundor333.com/post/2026/why-do-i-disinstall-poetry-and-use-only-uv-/

#poetry #pipenv #pyproject #pyenv #uv #makefile #make #precommit #dev #fingerfood

https://fundor333.com/post/2026/why-do-i-disinstall-poetry-and-use-only-uv-/

#poetry #pipenv #pyproject #pyenv #uv #makefile #make #precommit #dev #fingerfood

Let's say you want to do good type-checking for the #Python project you're working on. You pick a tool, maybe you use it as an #LSP also (so your editor can show you errors, too). As an example, I'm using #Ty at the moment. There's three places this might be installed: globally (e.g., `brew install ty`), as a dev-only dependency inside your project (e.g., `uv add --dev ty`), or -- and this one might surprise you -- it might only be used and installed by `pre-commit`, which builds a separate environment for each needed tool (which is great for instance where I use `codespell` as a `pre-commit` check, which seems to need some higher version of Python than my actual project).

Where should you install it?

If you're the only one on your team running it, globally is fine. If more than just you, then absolutely as a dev-only dependency inside your project ... and **maybe** globally as well.

The only real problem is updates. If you use a reasonable global install scheme, updates will be easy. They're less easy inside your project or in `pre-commit`. And you might care one way or the other! I **don't** want updates! I **do** want updates!

As for Python type-checking, `ty` seems good so far, but not enough experience with it yet. `basedpyright`, `pyrefly`, and `ruff` all good. These four are my favorites.

#BasedPyright #Pyrefly #Ruff #PreCommit #CodeSpell #Homebrew

Let's say you want to do good type-checking for the #Python project you're working on. You pick a tool, maybe you use it as an #LSP also (so your editor can show you errors, too). As an example, I'm using #Ty at the moment. There's three places this might be installed: globally (e.g., `brew install ty`), as a dev-only dependency inside your project (e.g., `uv add --dev ty`), or -- and this one might surprise you -- it might only be used and installed by `pre-commit`, which builds a separate environment for each needed tool (which is great for instance where I use `codespell` as a `pre-commit` check, which seems to need some higher version of Python than my actual project).

Where should you install it?

If you're the only one on your team running it, globally is fine. If more than just you, then absolutely as a dev-only dependency inside your project ... and **maybe** globally as well.

The only real problem is updates. If you use a reasonable global install scheme, updates will be easy. They're less easy inside your project or in `pre-commit`. And you might care one way or the other! I **don't** want updates! I **do** want updates!

As for Python type-checking, `ty` seems good so far, but not enough experience with it yet. `basedpyright`, `pyrefly`, and `ruff` all good. These four are my favorites.

#BasedPyright #Pyrefly #Ruff #PreCommit #CodeSpell #Homebrew

Eine Lösung, zumindest für #precommit : https://gist.github.com/schtobia/26e2b886d95a704a7db00e2dccd866de #forgejo