я использую пипенв потому что pipenv shell удобнее, чем . venv/bin/activate. Потому что из него можно выйти по C-d, а там надо deactivate

Вообще основной профит pipenv в отслеживании зависимостей, а не в управлении venv'ами

других отличий на самом деле для себя не вижу

1. В каких задачах необходимо отслеживание? 2. Допустим я фиксирую все зависимости для сервиса/программы м забываю про них. Зачем мне отслеживание?

1. Практически всегда необходима фиксации версий всех зависимостей (если только это не билиотека) 2. Как потом их обновлять? Как понять почему в requirements.txt есть та или иная зависимость если ты явно ее не используешь?

я использую пипенв потому что pipenv shell удобнее, чем . venv/bin/activate. Потому что из него можно выйти по C-d, а там надо deactivate

И ещё важно учесть, что докер твердым аргументом против pipenv, Если он используется

1. Это не задача. Так и есть, я легко делаю фиксацию через pip. Pipenv тут избыточен 2. Ну легко и просто: через pip апгрэйдим и дальше фиксируем. Операция по обновлению достаточно редкая, поэтому опять не вижу выгод тут у pipenv. Были бы такого рода операции частыми и очень вариативными по версиям библиотек, тогда он облегчил бы работу В первом сообщении я и указал, что pipenv для специфических задач. А на хайпе я указал потому, что часто его вижу необоснованно используемым в супер типовых задачах

Для меня пипенв удобнее, что зависимости сами записываются. Не надо pip install, pip freeze, копировать, вставлять в requirements.txt

А что докер?

А что докер?

Ну легко и просто: через pip апгрэйдим и дальше фиксируем Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать pip freeze > requirements.txt

Для меня пипенв удобнее, что зависимости сами записываются. Не надо pip install, pip freeze, копировать, вставлять в requirements.txt

я с пипенвом делаю pip install

Хотел спросить кстать, пользуешься Docker'ом?

Докеру не нужны всякие виртуальные окружения, там всё глобально в контейнер ставится

еще раз - pipenv shell это единственная команда пипенва, которую я использую. Там внутри - просто pip

не слышал о таком

пробовал использовать direnv?

хм. а оно с oh-my-zsh как дружит, не в курсе?

хм. оффтоп - как скинуть ссылку так, чтоб телеграм не пытался в пол-монитора превью показать?

хорошо

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

хм. а оно с oh-my-zsh как дружит, не в курсе?

Ну легко и просто: через pip апгрэйдим и дальше фиксируем Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать pip freeze > requirements.txt

Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать Это надуманная проблема, если такое и происходит(лично я вообще редко тяну еще какие-то ненужные для логики сервиса пакеты). И это разовая операция. РАЗОВАЯ!

Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать Это надуманная проблема, если такое и происходит(лично я вообще редко тяну еще какие-то ненужные для логики сервиса пакеты). И это разовая операция. РАЗОВАЯ!

Проблема с отсутствием тулов для нормального менеджмента всем этим барахлом.

что значит разовая? Зависимости в проекте имеют свойство меняться, добавляться, удаляться

ну так и меняется это ровно столько же раз в CI/CD, сколько меняется, добавляется, удаляется. Если это часто происходит, то вопрос к разработчику, чем он думал раньше и о чем

А как CI/CD решает эту проблему? Ты имеешь в виду, что разработчик добавляет зависимости в requirements.in, CI/CD потом генерирует lock-файл (requirements.txt) и коммит его в репозиторий?

чет я не уловил

да пох, пользуй pipenv

я подразумеваю, что всю рутину по сборке и доставке надо описывать в CI/CD. То что мы обсуждаем о pipenv и есть эта рутина для CI/CD. Еси понадобится описать какую-то кастомизацию одного сервиса через разные зависимости и их версии(что является редким случаем несущим больше проблем, т.к. поддержка такого кода требует много усилий, а соответственно должна быть твердо обоснованной), то эта кастомизация заносится в CI/CD , т.к. он является основным интерфейсом программным и графичексим для сборки и доставки. пользуйтесь pip, venv, отдавайте предпочтение минималистичности и простоте, если отсутствует прямая потребность в усложнении

чет мне он не нравится

я подразумеваю, что всю рутину по сборке и доставке надо описывать в CI/CD. То что мы обсуждаем о pipenv и есть эта рутина для CI/CD. Еси понадобится описать какую-то кастомизацию одного сервиса через разные зависимости и их версии(что является редким случаем несущим больше проблем, т.к. поддержка такого кода требует много усилий, а соответственно должна быть твердо обоснованной), то эта кастомизация заносится в CI/CD , т.к. он является основным интерфейсом программным и графичексим для сборки и доставки. пользуйтесь pip, venv, отдавайте предпочтение минималистичности и простоте, если отсутствует прямая потребность в усложнении

рутина по сборке и доставке и управление зависимостями это немного разные вещи

он мало кому нравится, кто плотно сталкивался с управлением зависимостями

зависимости прямым образом относятся к сборке, ну же

зависимости прямым образом относятся к сборке, ну же

Зависимости это воспроизводимость окружения в первую очередь

так собираешь то ты что? собираешь окружение...

мы пробовали вариант хуже - никакого pip, все ставится из своего репозитория yum. В него пакеты собирабются из pip в полуавтоматическом режиме

ну ок. Давай все же вернемся к вопросу о том как надо управлять зависимостями с помощью pip и CI/CD

Батл ?

В итоге отказались от этого?

в итоге при очередном рефакторинге забили. Как и на фриз, просто релизится docker-образ, каждый тестируем

file lock

file lock