Comments 15
Poetry был попыткой косплеить npm, предоставив разработчикам новый комбайн, вместо кучи лопат. Но мне кажется, что питон пошел пополз каким-то другим путём и у нас теперь, вместо одного понятного решения, есть конструктор для комбайнов https://packaging.python.org/en/latest/key_projects/ .
работаю по необходимости с poetry. Докину несколько рекомендаций
используйте virtualenv. На эту тему сломано много копий, есть за и против. У меня основной аргумент - при использовании virtualenv проще делать удалённую отладку через ide, потому что локальные и удалённые файлы будут по одним и тем же путям внутри virtualenv (ну и версия питона та же должна быть). Ещё это полезно для multistage сборок (в статье это есть, но не подчёркивается особо)
экономить место на образах питона - гиблое дело. Не надо этим заниматься, пока это точно не станет очевидным узким местом. Так же не надо делать mutlistage из этого соображения - ну и пусть у вас будут build tools и poetry в конечном образе, на фоне зависимостей обычного проекта это не играет роли
при установке вместо отключения кэша или его чистки, лучше использовать `RUN --mount=type=cache` например
RUN --mount=type=cache,target=/root/.cache \pip install ...опционально, версию poetry можно задавать через ARG
PYTHONUNBUFFERED=1, чтоб логи не залипали
в зависимости от flow разработки, выполнять или не выполнять `poetry lock --no-update` при сборке
для установки из приватного реестра пакетов использовать секреты для передачи пароля (не переменные или аргументы, потому что они останутся в образе)
Если есть возможность, лучше не делать сборку через Dockerfile. Лучше на уровне CI/CD использовать poetry для создания venv, а потом в Dockerfile использовать просто
COPY .venv .venv- всё таки в распространённых CI/CD система кэширования лучше работает с файлами, чем со слоями образов, и не надо думать, что в образе случайно останется чувствительная инфа или утилиты сборки не нужные в рантайме.Не забываем активировать virtualenv
ENV VIRTUAL_ENV=/app/.venvENV PATH="$VIRTUAL_ENV/bin:$PATH"
Большое спасибо за рекомендации, подчерпнул для себя много нового!
для установки из приватного реестра пакетов использовать секреты для передачи пароля (не переменные или аргументы, потому что они останутся в образе)
Спасибо. А можете привести пример?
RUN --mount=type=secret,id=PIP_EXTRA_INDEX_URL \
PIP_EXTRA_INDEX_URL=$(cat /run/secrets/PIP_EXTRA_INDEX_URL) \
poetry ....Документация тут https://docs.docker.com/build/building/secrets/
Poetry вещь хорошая, очень не хватает какого-то аналога npm. Если бы еще там не было глюков в новых версиях... Но из всего, что я пробовал, poetry и pipenv мне больше всех нравились.
Увы или к счастью, pypi теперь рекомендуют hatch. А poetry по-моему с самого начала выглядит как PoC Франкенштейна - ребята замахнулись сделать многое, но не вывезли ни чего сделать нормально и до конца.
У hatch на данный момент есть недостаток (на мой взгляд, довольно серьёзный):
The only caveat is that currently there is no support for re-creating an environment given a set of dependencies in a reproducible manner. Although a standard lock file format may be far off since PEP 665 was rejected, resolving capabilities are coming to pip. When that is stabilized, Hatch will add locking functionality and dedicated documentation for managing applications.
О! Тема, спасибо!
А вы пробовали PDM? Потому что пытались у нас внедрить Poetry, но потом я наткнулся на это видео и решил поискать что-нибудь ещё. Какое же было счастье, когда наткнулся на PDM. Самая главная фишка для меня — это возможность в конфиге прописать путь к .env файлам (и для отдельных скриптов тоже). Для меня странно, почему делают выбор в пользу Poetry.
Попробую сэкономить кому-нибудь десять минут жизни, которые у меня ушли на видео по ссылке: https://github.com/python-poetry/poetry/issues/6314
Установочный скрипт get-poetry.py был объявлен deprecated. В код добавили проверку на версию, и для версий ниже 1.2.0 он выдавал предупреждение, а для версий выше — завершался с ошибкой. Добавили этот код в версии 1.2.0a1.
Через год 1.2.0 вышла в релиз. Когда пользователи пришли в issues на github, разработчики пересмотрели свою позицию и оперативно выкатили исправление. Теперь установщик падал не при версии 1.2.0 и выше, а всегда, если запускать в пайплайне, и с вероятностью 1/20 (буквально, вызывая random.randrange) при запуске из командной строки.
Я пробовал pdm но он не смог справиться с установкой Rasa - падает на установке tensorflow/ Хотя описание у него прикольное по фичам.
PDM видел, но руки ещё не дошли попробовать. На Poetry сижу уже года полтора, пока что причин переходить на другой инструмент для себя не вижу (порой долгие резолвы, конечно, выматывают).
Poetry: from zero to hero