Comments 29
Собсно пара вопросов?
Почему кондовый loguru, который вообще не закастомизируешь?
Почему poetry, а не модный нынче uv?
loguru - потому что простой и все идет из коробки, не надо больше писать кучу бойлерплейт кода как в logging
uv буду обязательно пробовать в будущем, пока что времени совсем мало(
логуру простой, пока не надо его хоть немного кастомизировать. Ок :)
писать кучу бойлерплейт кода как в logging
Помилуйте , одним диктом все конфинурируется через dictConfig. Если хочется прям совсем просто, то basicConfig одной строчкой. Но если вам прям совсем лень даже доку прочитать на 15 минут, ну тогда наверное loguru для вас. До момента, когда понадобится понимать, как оно работает
Не сравнивали производительность драйверов БД на alpine vs. debian/ubuntu под нагрузкой? К производительности musl libc исторически были вопросы.
Я правильно понял, что вне докера приложения/сервисы вообще не запускаются? Например, просто локально на своём компе без докера, для быстрого дебага/теста. И поэтому нет необходимости в (ана)кондах и прочих менеджерах сред. Или как?
Приложения можно и нужно запускать локально, если так быстрее и легче дебажить. Однако Pycharm предоставляет возможность использовать удаленный интерпретатор, что в определённых ситуациях бывает даже удобнее (но вряд ли быстрее). Насчет менеджеров сред точно сказать не могу, я просто ими не пользуюсь.
То есть, нет необходимости вести несколько проектов с разными версиями всего?
Нет, вам достаточно прокинуть папку с кодом в волюмы и использовать везде одно и тоже. Вероятно, единственное, что будет отличаться адрес подключения к БД. Если запускаете приложение через докер, то надо вместо localhost писать имя сервиса. Это можно гибко настроить, но сейчас не смогу привести пример.
Посмотрите в сторону uv, он позволяет несколько версий питона держать, разные виртуальные окружения на их основе.
В Pycharm на столько кривая реализация удалённого интерпретатора, что количество жалоб на сайте jetbrains сравнимо с микроддос атакой. Да чего уж далеко ходить - сам буквально вчера в этом убедился. Вы тоже попробуйте, потому что складывается ощущение, что вы просто знаете что так можно делать, но не делали. В итоге все сводится к тому, что на локальной тачке после пары часов мучений с «возможностями» pycharm ты все равно создаешь venv и работаешь там.
Проблема на которой лично я решил прекратить поднимается здесь: https://youtrack.jetbrains.com/issue/PY-61111
И ни один из методов, которые предлагают jetbrains не работает по устранению проблемы. Ни какие танцы с pycharm_helpers не помогают. Вообще-то возникает вопрос, а для чего мне еще + 2 контейнера от pycharm нужны при этой процедуре, если они даже не запускаются при всей этой истории?
Pycharm амбициозная, но очень кривая ide практически во всем, что выходит за рамки «написать код, залить его по ssh».
Больше всего поразило, что файл с переменными .env вообще не существует для Pycharm в рамках совокупления с Docker интерпретатором. Мне пришлось их писать руками в Pycharm в настройках. Это не похоже даже близко на что-то удобное в принципе. Так и в чем разница, если с тем же подходом обычный source venv, как минимум, работает, а как максимум по количеству действий требует сильно меньше, чем совокупление pycharm с Docker (которое не работает)?
С некоторыми вещами это действительно криво работает, например, с FastAPI. Однако, я уже около года пользуюсь удаленным интерпретатором, работая с джанго. Да это медленно, да это кривовато, но на тяжеловесном приложении, где есть 8-10 контейнеров, легче запустить джангу через удаленный интерпретатор, чем танцевать с миллионом переменных окружения, которые нужно прокинуть в контейнер, чтобы там где надо подставилось название сервиса.
Также ничего не мешает вам создать докер конфигурацию для запуска своего кода. Да, медленно, но какие-то проблемы решает, где-то действительно легче так. Если инструмент не идеальный или вам не пригодился, это не значит что он плохой везде.
Насчет jetbrains согласен, их решения не помогают. Например, python3.13 + удаленный интерпретатор + Pycharm версии 22.1.3 вообще не стакаются вместе. Но если обновить pycharm, то, скорее всего, все взлетит (я не пробовал).
Если речь идёт именно о приложениях, чаще всего, подразумевается, что они должны работать в пачке. В таком случае самым простым и удобным, лично для себя, нашел перегрузку конфигураций для docker-compose и использование debugpy для отладки (dev-dependecies poetry). В pycharm или vsc - достаточно просто оставить дебаггеру открытый порт.
Проще и надёжнее отлаживать код в той среде, в которой он должен будет работать)
В SQLModel уже подправили костыли, чтобы Алембик заработал? И как запускаете все это дело на винде? Если WSL - то как решили проблему с подсказками в PyCharm (он требует локальный интерпретатор для показа всплывающей доки при наведении мышки на класс/метод). + Дебаг в WSL криво работал - не заходило в директории пакетов при дебаге (шагало только по своему коду)
alpine в качестве базового образа для Python проектов - довольно таки плохая идея.
Используйте для прода multistage build - отдельный образ с установкой poetry+сборкой зависимостей+созданием venv, а в финальный образ добавляем только этот venv и код проекта. Сам poetry далеко не пушинка (он вместе с зависимостями весит 70-100Мб), а если какие-то из пакетов требуют компиляции из исходников, то gcc/autoconf/make и т.п. весят ещё больше.
Зачем собирать образ дважды? Первый раз в CI ддобе, второй на хосте через docker compose up --build. Соберите образ один раз, положите в Dockerhub/Github registry, и на хосте выполняйте docker pull. Ну и для сборки в Github есть специальные actions, с кэшированием, multiarch и т.п., гораздо лучше сборки через docker compose.
Можно не прописывать запуск ruff через pre-commit и на уровне CI разными командами. Например для Github есть pre-commit.ci
У poerty совершенно непонятное (с корпоративной точки зрения) будущее. Всё выглядит так, что авторы собираются в какой-то момент собираются ввернуть официальную коммерческую поддержку, а это создаст большой риск в плане лицензии - см. историю с лицензированием redis. В этом плане pip+setuptools, за которым чисто python foundation стоит, выглядит куда более предсказуемо.
И да, pip умеет в pyproject с 2018 года.
Умеет ли пип правильно находить совместимые версии подзависимостей основных зависимостей? Когда я последний раз его использовал, он просто писал, что не может установить нужную версию, потому что конфликт версий. При этом поетри сам находил совместимую версию подзависимости, которая подходит для нескольких зависимостей одновременно.
Всё выглядит так, что авторы собираются в какой-то момент собираются ввернуть официальную коммерческую поддержку
А можно ссылку на источник?
Poetry не является, как основополагающим, так и безальтернативным инструментом. Никто не запретит в случае изменения политики пересобрать pyproject на проекте и заменить 2 строчки в Dockerfile в тот момент, когда это будет необходимо. Такие опасения в данный момент, не кажутся существенными, если как альтернативу рассматривать именно pip.
Pip все так же не умеет решать конфликты зависимостей, а для большинства - это практически единственная важная фитча поэзии. resolver - это шаг вперёд, но всё ещё не решение проблемы.
Про ruff знаешь, а про uv – нет? Странно, ведь автор у них один. Настоятельно рекомендую использовать в качестве замены для poetry.
Как я строю удобную инфраструктуру вокруг Python-проектов: линтеры, Poetry, CI/CD и Docker