Информация

Дата основания
Местоположение
Россия
Сайт
vdsina.ru
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 18

Зачем, если есть pipenv? Сейчас бы в 2к20 начинать проект на такой базе — красота (нет).

Добрый день, подскажите, чем плох virtualenv + requirements.txt?

Это слишком просто
сарказм

Пока вы перечисляете все зависимости (и зависимости зависимостей) указывая их точную версию, может и ничем.
Но 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 может оказаться весьма полезным.
Вот еще бы галочку «Inherit global site-packages» в PyCharm добавили. Два года назад попросил. Только еще один человек к просьбе присоеднился.

А у меня специфика scientific programming, т.е. куча мелких проектов, и везде нужен малый джентельменский набор numpy/scipy/matplotlib. А numpy/scipy я предпочитаю с MKL, а они поэтому кучу места на диске жрут…
Посмотрите, возможно Вам поможет моя статья: https://zhauniarovich.com/post/2020/2020-02-configuring-python-workspace/#my-configuration. Суть в том, что Вы можете создать одно pyenv окружение с установленным jupyter, numpy, scipy, matplotlib etc. и использовать его (у меня в отдельном окружении только jupyter установлен).
Так то понятно, что можно. Но вот отнаследоваться от такого виртуального окружения (создать новое с еще одним пакетом, а остальные взять из первого) ведь не получится? А иногда такие кирпичики иметь хочется.
Я сам не пользуюсь PyCharm'ом (использую VSCode), но может PyCharm сможет подхватывать глобальные пакеты из venv окружения, если проставить добавить include-system-site-packages в настройках?
Эта опция говорит о том, чтобы добавить в venv пакеты из python/lib/site-packages и сщщтвтствующего пользовательского каталога. Во-вторых, нафига нужно решение, работающее лишь в IDE, но не в обычной консоли?
Наверное, либо я что-то не понимаю, либо вы не совсем хорошо в теме копались. В консоли перед тем как использовать виртуальное окружение, его надо активировать (например, в моем случае для venv `source bin/activate`). Только что проверил, при активации опции include-system-site-packages вы видите пакеты из версии интерпретатора, который использовался для создания виртуального окружения. Так что можно использовать эту схему следующим образом. Используя pyenv создайте свои окружения, в которые установите ваши MKL зависимости, а потом создавайте виртуальные окружения наследуясь от этих pyenv окружений.
Дошло. Вы говорили про pyenv, я читал pipenv, о котором изначально шла речь. Увы, в Windows pyenv не поддерживатся. а venv/virtualenv/pipenv цепочек не поддерживают.
Я как-то наткнулся на pyenv-win, посмотрите, может покроет потребности и на вашей платформе.
Да я и так обхожусь… Вдобавок, я предпочитаю забирать numpy-MKL и scipy-MKL ручками c www.lfd.uci.edu/~gohlke/pythonlibs, а этот трюк вообще никто не поддерживает.
который использует curl | bash для начальной загрузки

Никогда не делайте три вещи:
Не используйте конструкции вида curl | bash на своих (а тем более, на чужих) устройствах
Не пишите и не переводите инструкций/статей без предупреждений, в которых используются конструкции вида curl | bash
Не рекомендуйте работников/авторов/инструкции/статьи, использующих/использующие конструкции вида curl | bash

P.S. вспомните меня, если когда лишитесь всех файлов в домашнем каталоге
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.