Comments 18
Зачем, если есть pipenv? Сейчас бы в 2к20 начинать проект на такой базе — красота (нет).
Это слишком просто
сарказм
Пока вы перечисляете все зависимости (и зависимости зависимостей) указывая их точную версию, может и ничем.
Но poetry и ему подобные инструменты могут "замораживать" установленные версии пакетов. Poetry записывает эти версии в poetry.lock. Таким образом вы можете воспроизвести установленные зависимости как на любой девелоперской машине, так и в продакшене.
Но poetry и ему подобные инструменты могут "замораживать" установленные версии пакетов. Poetry записывает эти версии в poetry.lock.
Так ведь и pip freeze делает то же самое — замораживает текущие установленные версии пакетов. Этого достаточно для того, чтобы воспроизвести окружение позже.
Другое дело, что в замороженный requirements попадают и зависимости, и зависимости зависимостей вперемешку, что может приводить к конфликтам в будущем, если список этих-самых зависимостей у какого-нибудь пакета изменится, однако на практике лично мне это никогда не мешало — достаточно просто держать отдельно requirements.txt со списком "зависимостей первого уровня" и requirements.freeze.txt для воспроизводимого окружения.
А теперь добавьте к этому шаблоны вроде "requirements.dev.txt" и "requirements.dev.freeze.txt" :)
Я ни в коем случае не оспариваю, что можно обойтись одним pip и virtualenv (идущим из коробки python3 -m venv). Но для меня poetry — это удобный высокоуровневый инструмент, который избавляет от рутины и тем самым уменьшает количество ошибок.
Другое дело, что в замороженный requirements попадают и зависимости, и зависимости зависимостей вперемешку, что может приводить к конфликтам в будущем, если список этих-самых зависимостей у какого-нибудь пакета изменится, однако на практике лично мне это никогда не мешало — достаточно просто держать отдельно requirements.txt со списком «зависимостей первого уровня» и requirements.freeze.txt для воспроизводимого окружения.
Кстати, для этих целей модуль pipdeptree может оказаться весьма полезным.
А у меня специфика scientific programming, т.е. куча мелких проектов, и везде нужен малый джентельменский набор numpy/scipy/matplotlib. А numpy/scipy я предпочитаю с MKL, а они поэтому кучу места на диске жрут…
который использует curl | bash для начальной загрузки
Никогда не делайте три вещи:
Не используйте конструкции вида curl | bash на своих (а тем более, на чужих) устройствах
Не пишите и не переводите инструкций/статей без предупреждений, в которых используются конструкции вида curl | bash
Не рекомендуйте работников/авторов/инструкции/статьи, использующих/использующие конструкции вида curl | bash
P.S. вспомните меня,
Настраиваем окружение Python с помощью pyenv, virtualenvwrapper, tox и pip-compile