#precommit — Public Fediverse posts

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

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

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

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

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

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

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

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

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.

#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.

#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.

#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

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.

prek 0.2.0 is out:

"Note: If you ran `prek install` in a repo before, you gonna need to run `prek install` again to replace the old git hook scripts for the workspace mode to work."

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

Here's a little script to run `prek install` in all subdirectories containing a config file:

uv run https://gist.github.com/hugovk/d601e651e08d229714a86fb5b04bc6c9

#Python #prek #lint #precommit #uv

🆕 I've been using a new tool called prek as a drop-in replacement for pre-commit.

It uses uv and is rewritten in Rust (because of course) and as you'd expect is much faster.

Try it!

https://hugovk.dev/blog/2025/ready-prek-go/
#Python #prek #lint #precommit #uv

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)

I have a simple script that adds and updates dates in a blog post by prek (precommit) before git commit.

It works well in linux, but does not work as expected on macos. In Mac it sets initial time, but does not update it.

I thought it’s very simple bug, very good to delegate to AI coding tool, my AI agent was github copilot.

Copilot generated me nodejs code inside bash to fix the issue, but it did not. It rewrote almost completely my bash script to nodejs, but it did not work as well.

When I gave up and checked by myself, it required to add “-u” option to “date” cli for macOS.

There was an another task that involved another git command’s parameters and “AI” decided to add 20 lines of code with no positive result.

How do people build a startup and fully functional apps with it?

I use it for function generations, tests, structs… but when it goes to something more complicated it never works with “good enough” quality for me.

#prek #precommit #linux #macos #ai #github #github_Copilot #bash #nodejs #startup #git

ИИ бот-модератор 1: Начало проекта

Знаете, в чём проблема большинства гайдов и курсов, которые обещают научить всему и сразу — да ещё и устроить на работу? Часто они учат примитиву, выдавая это за качественный контент. В итоге появляется много низкокачественного кода: на первый взгляд он работает, но в реальности трудно поддерживается . Если в проекте нет структуры, он быстро превращается в кашу. Каждая доработка — это не отдельный продуманный модуль, а «приматывание новых кусков кода синей изолентой» с мыслью: «хоть бы не сломалось». Для новичка это особенно опасно: кажется, что всё нормально, пока проект маленький, но при росте даже простые изменения начинают занимать часы и ломать соседние части. Вы наверняка задаётесь вопросом: «Почему рубрика называется “ИИ бот-модератор”, а автор тут рассказывает про качество кода?» На самом деле, всё связано. Telegram-бот для группы — отличный пример проекта, который очень быстро обрастает фичами: команды, настройки, роли, интеграции, хранение данных, логирование, админка, модерация, ИИ и т.д. Если делать всё “в одном файле”, это почти гарантированно закончится болью. Поэтому в этой рубрике мы будем строить бота так, чтобы его можно было развивать: добавлять функциональность без постоянного страха «сломать всё».

https://habr.com/ru/articles/978282/

#telegram #бот #ии #git #make #precommit #линтеры #ruff #ry #uv

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

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

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

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

My friend Jim @jammcq and I were discussing #precommit (used with #Git). The typical case is simple but annoying:

* You’ve staged all the needed files for commit (with `git add`)
* You attempt the commit
* Trailing whitespace (in this example) makes `pre-commit` deny the commit
* No commit actually happened. Everything in the staging area is untouched. Code in your working copy has been changed to fix the problem.
* Those fixes must now be staged (another call to `add`)
* You must re-run the commit

Sure, the up-arrow helps, but still.

Here’s another way:

* You happen to be working on the file `foo.py`; but you haven’t staged anything yet. You’re just editing away
* Let’s fix some whitespace problems: `pre-commit run trailing-whitespace --files foo.py`
* `foo.py` is modified in-place, now `add` and `commit`
* Shorten the long `pre-commit` command with an alias; you control the exact conditions to look for and fix

Is it better? Well … it’s different. It’s better in some ways. It might be a better fit for the way you personally work.

@amedee pre-commit is brilliant, so versatile, I recently wrote about using `pytest-testmon` as a pre-commit hook.

https://blog.nshephard.dev/posts/pytest-testmon/

#precommit #git #hooks

OOF. My fancy Catpuccin wezterm theme + pre-commit makes for one :blobsad: partially blind guy. Time to revert my wezterm config unless I can figure a work-around!

#catpuccin #wezterm #precommit

As a software developer, you can assume that an attacker knows you have credentials.

The risk of supply-chain attacks means that your development environments (running NPM, PyPi etc.) should at least run in Docker, not alongside your ~/.ssh folder and your ~/.pypirc.

On that note, I'm still very unsure about the future of #precommit as a virtual environment manager (even sources stuff directly from Git repositories).

https://infosec.exchange/@dangoodin/115248738646268206

Running uv and pre-commit in a container (like on github actions), it looks simple but yet it took me many iterations to get there (i am sure someone may mentions a better way)

python3 -mpip install -U uv
uv sync
export PATH="$PATH:$(pwd)/.venv/bin"
uv add pre-commit ruff pylint
.venv/bin/pre-commit run -a

#github #Python #ci #precommit

Nuevo artículo: «Configurando pre-commit con ruff para un proyecto en Python»
https://andros.dev/blog/fa7d1929/configurando-pre-commit-con-ruff-para-un-proyecto-en-python/

Cuando utilizas Git, dispones de una herramienta muy poderosa llamada hooks. Te permite lanzar scripts en diferentes momentos del ciclo de vida de un repositorio. Por ejemplo, puedes ejecutar un comando después de hacer un push, el cual podría desplegar el código a un servidor, o lanzar un software que se ejecute antes de hacer un commit para asegurarte de que el código cumple con ciertas normas. Y aquí es donde entra en juego pre-commit.

#python #uv #ruff #precommit #git #anuncios

How is #precommit even a thing?

https://pre-commit.com/

There's apparently _no_ security whatsoever. It just downloads random code from the internet and runs it on your machine.

And everyone with write access to the repo can just tell it to download _more_ code.

Compare this to direnv (https://direnv.net), which will ask you for permission every time someone changes its config.

#Python #security

Take your Odoo development to the next level by automating code quality checks with pre-commit hooks and GitHub CI. Enforce standards, catch errors early, and streamline your workflow. #Odoo #DevOps #precommit #CI #Python

https://teguhteja.id/automate-odoo-code-quality-with-pre-commit/

Unlock flawless Odoo development! Use pre-commit Odoo apps with OCA hooks to automate linting, enforce quality, and streamline CI workflows. #Odoo #precommit #OCA #DevOps #Python

https://teguhteja.id/pre-commit-odoo-apps-automation-guide/

Как я строю удобную инфраструктуру вокруг Python-проектов: линтеры, Poetry, CI/CD и Docker

Poetry вместо pip, Ruff вместо flake8, FastAPI вместо ручной документации. Что реально упрощает жизнь Python-разработчику сегодня — на примерах и с реальными конфигами.

https://habr.com/ru/articles/904844/

#python #fastapi #pydantic #docker #poetry #infrastructure #devops #ruff #управление_разработкой #precommit

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

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

I have a simple script that adds and updates dates in a blog post by prek (precommit) before git commit.

It works well in linux, but does not work as expected on macos. In Mac it sets initial time, but does not update it.

I thought it’s very simple bug, very good to delegate to AI coding tool, my AI agent was github copilot.

Copilot generated me nodejs code inside bash to fix the issue, but it did not. It rewrote almost completely my bash script to nodejs, but it did not work as well.

When I gave up and checked by myself, it required to add “-u” option to “date” cli for macOS.

There was an another task that involved another git command’s parameters and “AI” decided to add 20 lines of code with no positive result.

How do people build a startup and fully functional apps with it?

I use it for function generations, tests, structs… but when it goes to something more complicated it never works with “good enough” quality for me.

#prek #precommit #linux #macos #ai #github #github_Copilot #bash #nodejs #startup #git

I have a simple script that adds and updates dates in a blog post by prek (precommit) before git commit.

It works well in linux, but does not work as expected on macos. In Mac it sets initial time, but does not update it.

I thought it’s very simple bug, very good to delegate to AI coding tool, my AI agent was github copilot.

Copilot generated me nodejs code inside bash to fix the issue, but it did not. It rewrote almost completely my bash script to nodejs, but it did not work as well.

When I gave up and checked by myself, it required to add “-u” option to “date” cli for macOS.

There was an another task that involved another git command’s parameters and “AI” decided to add 20 lines of code with no positive result.

How do people build a startup and fully functional apps with it?

I use it for function generations, tests, structs… but when it goes to something more complicated it never works with “good enough” quality for me.

#prek #precommit #linux #macos #ai #github #github_Copilot #bash #nodejs #startup #git

I have a simple script that adds and updates dates in a blog post by prek (precommit) before git commit.

It works well in linux, but does not work as expected on macos. In Mac it sets initial time, but does not update it.

I thought it’s very simple bug, very good to delegate to AI coding tool, my AI agent was github copilot.

Copilot generated me nodejs code inside bash to fix the issue, but it did not. It rewrote almost completely my bash script to nodejs, but it did not work as well.

When I gave up and checked by myself, it required to add “-u” option to “date” cli for macOS.

There was an another task that involved another git command’s parameters and “AI” decided to add 20 lines of code with no positive result.

How do people build a startup and fully functional apps with it?

I use it for function generations, tests, structs… but when it goes to something more complicated it never works with “good enough” quality for me.

#prek #precommit #linux #macos #ai #github #github_Copilot #bash #nodejs #startup #git

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