LINUX.ORG.RU

Стратегия работы с requirements.txt

 , , ,


0

1

Есть контейнер, в requirements.txt пакеты вида(как пример):

# aiohttp
aiohttp==3.7.4.post0
cchardet==2.1.7
aiodns==3.0.0
aiohttp-devtools==0.13.1

# serve
gunicorn==20.1.0

# config
pyyaml

# db
aiopg==1.3.2
asyncpg==0.24.0

# validation
aiohttp-apispec==2.2.1

# admin
aiohttp-admin2==0.0.5

Всё это устанавливается в контейнере. Но иногда при установке с нуля контейнера всё это ломается. Такое ощущение, что зависимости меняют свои версии. Как вообще правильно делать? Если делать после установки в контейнере

pip freeze > requirements.txt

То имеем кашу:

cat ./app/requirements_freeze.txt
aiodns==3.0.0
aiohttp==3.8.3
aiohttp-admin2==0.0.5
aiohttp-apispec==2.2.3
aiohttp-devtools==1.0.post0
aiohttp-jinja2==1.5
aiomysql==0.0.21
aiopg==1.3.5
aiosignal==1.2.0
anyio==3.6.1
apispec==3.3.2
asttokens==2.0.8
async-timeout==4.0.2
asyncpg==0.26.0
attrs==22.1.0
cchardet==2.1.7
cffi==1.15.1
charset-normalizer==2.1.1
click==8.1.3
devtools==0.9.0
executing==0.10.0
frozenlist==1.3.1
greenlet==1.1.3.post0
gunicorn==20.1.0
idna==3.4
Jinja2==3.1.2
MarkupSafe==2.1.1
marshmallow==3.18.0
motor==2.5.1
multidict==6.0.2
mypy==0.982
mypy-extensions==0.4.3
packaging==21.3
psycopg2-binary==2.9.4
pycares==4.2.2
pycparser==2.21
Pygments==2.13.0
pymongo==3.12.3
PyMySQL==0.9.3
pyparsing==3.0.9
python-dateutil==2.8.2
PyYAML==6.0
six==1.16.0
sniffio==1.3.0
SQLAlchemy==1.4.41
sqlalchemy-stubs==0.4
tomli==2.0.1
typing_extensions==4.4.0
umongo==3.1.0
watchgod==0.8.2
webargs==5.5.3
yarl==1.8.1

Уже не ясно, что есть пакет, а что есть зависимость. Отдельно держать файл с пакетами(первый вариант) и постоянно его актуализировать и постоянно в контейнере выполнять

pip freeze > requirements.txt

думаю неправильно. Как вообще сделать так, чтобы всё это хозяйство было статичным и не ломалось при пересборке контейнера с нуля т.е гарантировать, что после сборки контейнера - всё работало внутри? Может как-то сохранять локально и потом копировать внутрь контейнера?

★★★

Последнее исправление: serg002 (всего исправлений: 1)

Но иногда при установке с нуля контейнера всё это ломается. Такое ощущение, что зависимости меняют свои версии.

Перестать использовать pip и начать использовать poetry. pip - низкоуровневый неудобный инструмент, и да: он не умеет правильно резолвить и фризить зависимости.

Раньше не умел, во всяком случае, и все перешли на poetry, и даже если он вдруг научился (движения такие были, не знаю, чем закончились), то всё равно poetry на порядок удобнее.

emorozov
()

Я ничего в питон не понимаю, но напрашивается вариант с requirements-short.txt и requirements-full.txt. В первом руками ставишь зависимости, второй генерируешь из первого и используешь реально.

vbr ★★★★
()
Ответ на: комментарий от firkax

ох уж эти докеропроблемы

Докер тут совсем не причём, если проблема с зависимостями проекта.

vvn_black ★★★★★
()

Может как-то сохранять локально и потом копировать внутрь контейнера?

Почему бы и нет, хоть в гит положи, да обновляй когда будет морально готов. А при обновлениях будет дифф на случай, если что-то сломается.

Способ топорный, но относительно простой и работающий.

melkor217 ★★★★★
()

можно pip install –target=/где-то/рядом все_подряд_requirements. потом export PYTHONPATH=/где-то/рядом. папку /где-то/рядом положить рядом с проектом(или куда нужно).

или использовать venv.

nionio35
()
Последнее исправление: nionio35 (всего исправлений: 1)
Ответ на: комментарий от eternal_sorrow

Не все.

Здесь все ответы предлагают либо неверный ответ (не решающий проблему из вопроса), либо какой-то неудобный вариант.

poetry решает проблему из изначального вопроса, делает это просто и элегантно.

(Нет)

Какой же вариант удобнее? Поддерживать месиво из .txt файлов и обновляющих их скриптов, точно не удобнее и не проще.

emorozov
()
Ответ на: комментарий от emorozov

poetry решает проблему из изначального вопроса, делает это просто и элегантно.

До тех пор пока poetry не будет предустановлена в любом виртуальном окружении, созданном через python -m venv, poetry не будет альтернативой pip.

eternal_sorrow ★★★★★
()
Ответ на: комментарий от emorozov

poetry не стоит использовать, потому что разработчики подорвали доверие к своему проекту. Ваш CI просто упадёт с некоторой вероятностью, потому что мэйнтейнеры думают, что это правильный способ дипрекейтить некоторые фичи.

https://github.com/python-poetry/poetry/pull/6297

https://www.youtube.com/watch?v=Gr9o8MW_pb0

kukuruku ★★
()
Ответ на: комментарий от qaqa

хорошо, а распишите на моём примере в топике, как вы это будете делать с этим подходом. Вангую, что этот способ будет очень сильно похож на тот, что я описал(отдельный файл и пип фриз)

serg002 ★★★
() автор топика
Последнее исправление: serg002 (всего исправлений: 1)
Ответ на: комментарий от serg002

не совсем, потому что зависимости из constraints.txt не устанавливаются, этот файл только лочит версии для транзитных пакетов. Отличие в том, pip install запускается один раз. Апгрейдить версии нужно только через предварительное тестирование. Ну если нужно, чтобы версии вообще никогда не менялись, то одного requirements.txt хватит.

kukuruku ★★
()
Ответ на: комментарий от kukuruku

Разработчики скрипта get-poetry.py облажались. Печально, но это не конец света, и такое происходило и будет происходить с каждой программой. Людям свойственно ошибаться, и это ещё не самая страшная ошибка.

Кроме того, я вообще впервые вижу людей, которые используют get-poetry.py, особенно, в CI пайплайнах, где этот скрипт, на мой взгляд, вообще не нужен.

Не могу понять, почему один баг в одном скрипте обесценивает весь подход в целом.

Ну, конечно, лучше уж пердолиться с закатом солнца вручную через наборы текстовых файлов и вызовы скриптов в нужном порядке. Не говоря о том, что poetry автоматизирует гораздо больше, чем установка зависимостей.

emorozov
()

Меняют версии скорее всего зависимости уровня N+1.

upcFrost ★★★★★
()
Ответ на: комментарий от melkor217

это не топорный способ, а индустриальный стандарт

max_lapshin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.