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.

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

[prek - Rust로 재개발한 더 나은 pre-commit

prek는 Rust로 재개발된 pre-commit 대체 도구로, Git hook 관리의 속도와 효율성을 높이는 것을 목표로 합니다. 병렬 처리 구조를 통해 훅 설치 및 실행 시간을 단축하며, 주요 프로젝트에서 이미 채택되고 있습니다. 다중 언어 툴체인 통합 관리, 워크스페이스 환경 지원, 향상된 CLI 명령어, 공급망 공격 완화 기능 등을 제공합니다.

https://news.hada.io/topic?id=27066

#rust #git #precommit #devtool #monorepo

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

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

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

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

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

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

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.