Концепция venv (virtualenv) в Python

Концепция крутая, как по мне ноутбуки и виртуальные окружения - две самые крутые фичи в Python.

Если вкратце о ее сути: ты создаешь для каждого проекта отдельную виртуальную среду, со своим интерпретатором Python (разные версии) и своим набором библиотек.
Это удобно, и решает проблему конфликта зависимостей. Небольшое уточнение: если бы все сервисы и библиотеки явно указывали версии зависимостей - конфликтов бы не было, но мы же говорим о реальном мире.
К слову, концепцию позаимствовала и Java, я про jenv - https://t.me/javaKotlinDevOps/442 - правда, ограничить можно только версию Java.

Но блин.
Почему утилит, реализующих виртуальные окружения столько:
- venv
- virtualenv
- uv
- Poetry
- PDM
- Hatch
- Rye
- Conda
- Mamba
- Micromamba
- Pixi
- Pipenv
- pyenv-virtualenv
- virtualenvwrapper
- Tox
- Nox
- Devbox
- Flox
- Devenv.sh
- Spack
- Vex
????

Явная иллюстрация анекдота про 10 стандартов)

Ясно, что они не идентичны по функционалу.
1) кто-то добавляет возможность менеджера пакетов (и это правильно),
2) кто-то позволяет формировать список зависимостей проекта requirements.txt (и это тоже правильно),
3) кто-то добавляет возможность делать lock зависимостей (спорная фича IMHO).
Кто-то просто устарел. Кто-то заточен для тестов, где нужна куча разных сред. Кто-то просто добавляет небольшие фишки в другой менеджер, типа убирает необходимость явно включать использование виртуального окружения в консоли (activate).
Но все же...
Причем 4 из них имеют официальный статус)

P.S. Самой крутой и современной считается uv. На данный момент.

#python #java #virtual_env

Про практическое применение AI в разработке

"Низколежащий фрукт" - добавление в проект новых зависимостей.
В IDEA как бы есть для этого auto complete в build и pom файлах. Но работает он... плохо.

Maven. Я вбиваю любую часть имени groupId или artefactId зависимости - и IDE мне ее находит и подставляет всю конструкцию:
<dependency>
...
</dependency>
С плагинами тоже работает, правда есть один момент - у зависимостей и плагинов общий индекс, поэтому чтобы искать плагины нужно вначале вбить groupId. А у всех стандартных плагинов он одинаковый - org.apache.maven.plugins.

Вроде все работает? Нет. Заставить работать индекс по mavenCentral у меня не получилось. А что же работает? Поиск по зависимостям из локального репо. Но его вначале нужно наполнить. Причем эту проблему - поиск по удаленному репозиторию - я помню уже лет 5 минимум.

С Gradle все еще хуже. Тоже ищет только локальные зависимости, но работать нормально не возможно. Для добавления зависимости вначале нужно написать implementation, и начать набирать точное имя зависимости с начала. А плагины не ищет совсем.
Пробовал с Groovy и Kotlin DSL.

Так что тут AI спасет. Но в агентском режиме, не auto complete, т.к. для работы auto complete нужен электрод в мозг, а до этого техника еще не дошла. Т.е. нужен немного другой паттерн работы, но это в целом касается работы с AI.

#maven #gradle

Я вообще хотел написать пост о том, как IDEA по разному работает с Maven и Gradle.
Но потом понял корень проблемы, вспомнил, сколько ей лет, и "Остапа понесло" на тему AI)