#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

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

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)

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.

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

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

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

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