pip freeze что это
Pip freeze что это
pip freeze requirements.txt — команда, которая позволяет создать текстовый документ в котором перечислены все установленные и необходимые для работы Python приложения программные пакеты (чаще всего Django).
Список всех пакетов можно посмотреть выполнив pip freeze — стандартный вывод производится на экран. Обычно эту информацию сохраняют в файл, который оставляется в корне приложения и переносится на другой сервер вместе с ним.
Перенос проекта на Python с pip freeze и requirements.txt
На исходном сервере выполняем следующую команду указывая путь к файлу, в котором будет сохранена информация, которая потребуется для корректной работы проекта
Если используется виртуальное окружение команду нужно выполнять в нем.
Виртуальное окружение можно активировать выполнив source /project-folder/bin/activate
Установка всех пакетов по списку производится при выполнении
Внесение изменений в requirements.txt вручную является не самой лучшей практикой поскольку автоматическая установка пакетов их этого файла в большинстве случаев окажется невозможна.
Также при запуске сайта после переноса может оказаться полезной команда (часто после переноса проект запускается, статическое содержимое при этом не отдается)
Она позволяет собрать статику в STATIC_ROOT. При этом если существуют файлы с одинаковым именем обработан будет только один из них (какой файл использует сайт можно выяснить при помощи findstatic — используется так — django-admin.py findstatic /path/to/the/folder, в выводе будут все файлы изображений, CSS стилей и т.п.; также команду можно запускать с ключом —first. в этом случае в вывод попадет только первое вхождение, далее поиск прекратится).
Запускается проект (в случае Django) стандартно с указанием файла django-admin.py и имени проекта
python django-admin.py startproject projectname
А как вам такой вариант управления зависимостями в Python?
Недавно я решил, что пора наконец-то разобраться в теме управления зависимостями в моих Python проектах и начал искать решение, которое бы меня полностью устроивало. Я поэкспериментировал с pipenv, проштудировал документацию к poetry, почитал другие статьи по теме. К сожалению, идеального решения я так и не нашел. В результате, я изобрел новый велосипед свой подход, который и предлагаю обсудить под катом.
Проблема
Но перед тем как непосредственно перейти к описанию подхода, мне бы хотелось объяснить, почему возникла такая необходимость и чем меня не устроивали существующие решения.
В рамках моей работы чаще всего я использую Python в двух целях: это либо анализ данных и машинное обучение используя блокноты Jupyter, либо небольшие Python скрипты, которые каким-то образом подготавливают данные. Хочу отметить, что я не занимаюсь созданием пакетов и их публикацией в Pypi (поэтому не акцентирую внимание на этом процессе в этой статье).
Очень часто мне требуется запускать скрипты или блокноты, которые были созданы довольно давно. Поэтому у меня возникла необходимость каким-то образом фиксировать версии зависимостей и запускать скрипты и блокноты в виртуальном окружении. С другой стороны, иногда в новой версии какой-либо библиотеки может появиться функциональность, которая позволит улучшить результаты старого блокнота или скрипта. Например, в scikit-learn (библиотека для машинного обучения) могут добавить имплементацию нового алгоритма, который отлично подходит для моего случая.
Очень часто при разработке какого-то скрипта, я также вынужден устанавливать какие-то дополнительные зависимости, которые требуются только для разработки. Например, так как я использую VSCode для разработки, то он требует, чтобы в виртуальном окружении был установлен pylint. Другие люди, с которыми я сотрудничаю, могут использовать другие инструменты для разработки, которым эта зависимость совершенно не требуется.
Исходя из этих предпосылок, у меня сложились следующие требования для управления зависимостями:
Канонический подход по управлению зависимостями, когда создается отдельное виртуальное окружение для проекта и когда версии всех зависимостей фиксируются (используя pip freeze > requirements.txt ) в requirements.txt, не работает исходя из моих требований. Во-первых, он не позволяет разделить центральные и зависимости необходимые только для разработки. Во-вторых, в этом случае requirements.txt содержит все зависимости и их подзависимости, поэтому искать версию определенной библиотеки становится проблематичным.
Исходя из этих требований, оптимальным решением казалось использование pipenv (вот, например, статья о том, как использовать этот инструмент). Но когда я начал экспериментировать с ним, я выяснил, что у него есть несколько недостатков. Например, когда я использовал его для установки библиотек, он иногда полностью зависал или работал на редкость медленно. Поэтому после нескольких неудачных попыток, я решил дальше не продолжать с ним, хотя он идеально подходит исходя из моих требований. Poetry же не работает для управления зависимостями для блокнотов.
Решение
Прежде всего, хочу отметить, что я в качестве операционной системы использую (k)Ubuntu 18.04. Если у вас другая операционная система, возможно потребуется адаптация моего подхода. Если вы адаптируете этот подход под другую операционку, то было бы здорово, если бы вы поделились им в комментариях.
Таким образом, в репозитории вместе с проектом я храню 4 файла: requirements.txt, requirements-dev.txt, requirements.lock и requirements-dev.lock.
Исходный код этих двух функций хранится у меня в файле (Всегда проверяйте исходники. ). Вы можете скопировать его в директорию
Заключение
Я только начал использовать это решение и возможно ещё не обнаружил какие-то недостатки. В целом, этот пост задумывался для того, чтобы обсудить этот подход и есть ли у него права на жизнь. Если вы видите какие-то проблемы, то буду очень рад услышать о них.
Если вам интересно узнать о том, как я настраиваю свое Python окружение, то я написал очень длинную статью (на английском) по этой теме у себя в блоге.
requirements.txt — что это и зачем?
В исходниках множества Python-проектов можно встретить этот странный текстовый файл. Например, им пользуются urllib3, numpy, pandas, flake8 и куча других проектов. Давайте разберемся, что это такое, как этим пользоваться и зачем нам это нужно.
Гипотетическая предыстория
Давайте представим, что вы написали замечательный скрипт, который спрашивает у пользователя название города и выводит текущую температуру и общее состояние погоды:
Скрипт получился настолько хорош, что вы хотите поделиться им со всеми своими друзьями. К сожалению, друзья при попытке запустить вашу программу получают следующую ошибку:
Кажется, что скинуть только код недостаточно.
Или, допустим, что вы сами через полгода-год попытаетесь запустить эту же программу. За это время вы успели пару раз переустановить Python, переустановить ОС, отформатировать свой магнитный накопитель (используйте SSD — нет, я серьёзно!) или может быть вообще сменили компьютер. Почти уверен, что при запуске скрипта вы получите ровно ту же самую ошибку.
Зачастую, когда мы пишем код, мы полагаемся на какие-либо библиотеки или фреймворки. Это со всех сторон хорошо — это удобно, уменьшает размер программы во много раз, позволяет не думать о мелких деталях, а решать свою конкретную задачу, опираясь на высокоуровневые абстракции. Но, к сожалению, есть «но» — такие библиотеки становятся частью вашей программы, ваш код становится зависим. Это значит, что ваш код больше не сможет работать сам по себе, для его работы должны быть установлены все зависимости.
Я хочу сказать, что намного мудрее составлять этот список зависимостей сразу же и просто поддерживать его в актуальном состоянии по мере развития проекта.
requirements.txt — это список внешних зависимостей
Сообщество Python исповедует идеологию «простое лучше, чем сложное». Наверное, поэтому для хранения списка зависимостей сообщество выбрало самый простой из возможных форматов — текстовый файл, где на каждой строке перечислено ровно по одной зависимости.
Стоит отметить, что requirements.txt не является стандартом, т.е. нет документа, который описывал бы требования к этому файлу. Скорее, это просто распространённая практика в сообществе, которая, наверное, возникла спонтанно и хорошо прижилась.
Вот пример самого простого такого файла (кстати, именно этим файлом можно описать зависимости, которые нужны для запуска нашего скрипта с погодой):
Если бы было несколько зависимостей, то файл выглядел бы так:
Можно указать конкретную версию зависимости. Если версия не указана, то считается, что нужна последняя доступная:
Можно указывать диапазоны и другие более сложные «спецификаторы версий». В целом, в requirements.txt можно писать любые «запросы», которые понимает команда pip install :
Как пользоваться
Команда pip install умеет читать такие файлы, если передать специальный флаг:
Таким образом, если requirements.txt будет иметь вот такое содержимое:
То следующие две команды будут иметь одинаковое действие:
Преимущества использования requirements.txt :
На таком маленьком примере разница может быть не очевидна, но когда список зависимостей разрастётся до определенного размера, то вам не захочется больше перечислять его в pip install напрямую.
Так как это распространённое соглашение, то другим разработчикам будет достаточно увидеть этот файл, чтобы понять, что нужно сделать. Это здорово экономит время на чтении инструкций.
Как создать
Но можно использовать и встроенную в pip функциональность:
Команда pip freeze выводит все установленные в интерпретатор сторонние пакеты. Заметьте, что в список попали не только прямые зависимости ( pyowm ), но и подзависимости — это даже лучше, потому что вы сможете более точно воссоздать окружение по этому файлу.
Можно перенаправить вывод этой команды в файл при помощи стандартного консольного приема (работает и на Windows), и получить валидный файл requirements.txt :
Обратите внимание, что pip freeze выведет список пакетов в том окружении, в котором он запущен. Не забудьте активировать виртуальное окружение перед запуском этой команды, иначе получите список пакетов, установленных в глобальный интерпретатор. Кстати, у меня есть пост про виртуальные окружения, где объясняется как ими пользоваться.
Подытожим плюсы и минусы ручного и автоматического подходов:
Можно использовать и смешанный подход: сгенерировать начальную версию файла при помощи pip freeze и допилить её затем руками, если у вас какая-то сложная нестандартная ситуация.
Проблемы requirements.txt
Почему «хотя бы примерно»? Практика показывает, что зафиксировать версию пакета недостаточно. Иногда случается, что под одной версией пакета в разное время может находиться совершенно разный код. PyPI, конечно, не позволит перезаписать уже опубликованную версию, но, например, ваш приватный корпоративный индекс пакетов может быть не таким строгим.
Заключение
Для тренировки можно попытаться запустить скрипт с погодой. Все исходники лежат здесь.
Дополнительное чтение
Подпишитесь!
Чтобы получить уведомление о новом посте можно:
Почему я ненавижу virtualenv и pip
venv и иллюзия изоляции
Изоляция и легко воспроизводимое чистое python-окружение безо всяких скрытых зависимостей от основной операционной системы это, определённо, хорошая вещь. Основная цель venv — предоставление удобного способа изоляции на уровне python’а. Но тут не всё идеально: для тех пакетов питона, которые зависимы от системных библиотек, изоляция осуществляется лишь частично, распространясь только на python-составляющую этих пакетов. Если разработчик в курсе этого — всё еще не так плохо, но вот если нет — он может столкнуться с серьёзными и непонятными ему проблемами.
Полные методы изоляции приводят к избыточности venv
venv это антипаттерн развёртывания
venv полон костылей
Когда вы устанавливаете venv, он на самом деле не пуст. В директорию lib/ копируется вся стандартная библиотека питона. В include/ — пачка питоньих заголовочных файлов. Смысл существования этих директорий кажется мне надуманным (подробнее в следующем параграфе), но гораздо больше меня раздражает bin/. В bin/ лежат pip и easy_install. venv портит shebang’и их обоих, чтобы запускать их не под системным, а под лежащим в той же директории интерпретатором python’а. Shebang’и всех прочих скриптов от дополнительно установленных пакетов портятся точно таким же образом. И вам приходится поддерживать это поведение venv и следить за shebang’ами постоянно, пока вам нужно работать со скриптами, лежащими внутри venv, «снаружи», например, запуская их через системный cron. Вам приходится «захардкоживать» путь к соответствующим venv, чтобы скрипт запускался под нужным интерпретатором. Это, как минимум, так же утомительно, как и вручную настраивать PATH/PYTHONPATH. На самом деле, проще ничего не делать, но я вернусь к этому чуть позже.
Ой, я забыл упомянуть bin/activate
—no-site-packages
pip и venv это отличная связка
Все так думают лишь потому, что они написаны одним и тем же человеком — Ian Bicking. У обеих программ своя собственная философия и свои собственные варианты использования. Мне не нравится venv по большей части потому, что он заставляет людей верить, но я допускаю, что у него есть своя ниша. На самом деле я сам им пользуюсь время от времени для быстрых одноразовых тестов. Но pip с другой стороны не должен был рождаться вообще. Он — лишь «почти-совместимая» альтернатива easy_install с дополнительными свистоперделками, которых бы лучше не было вовсе. Заместо него я предпочитаю использовать easy_install вкупе с такими интерактивными и не очень программами как puppet или вообще компиляцией пакетов из исходников. Может показаться, что у меня предвзятость против pip, но это не так. Я согласен, что в чём-то приятнее писать в консоли pip install, нежели easy_install. easy_install звучит как-то глупо. Да и нижнее подчёркивание в имени это явно не практично. Готов поспорить, что одно лишь имя обеспечивает pip’у некоторую часть его популярности.
pip каждый раз собирает из исходников
Этот чёртов requirements.txt
Чтобы объявить необходимые зависимости для своего пакета, можно указать их в install_requires в setup.py. Это python way. setuptools/distribute реализуют этот механизм, и он используется как easy_install, так и pip для автоматической загрузки с Pypi и установки этих зависимостей. По причинам, которые слишком долго объяснять, pip также позволяет указать список зависимостей в текстовом файле. Обычно он называется requirements.txt. Его синтаксис точно такой же, как в setup.py, но у него также есть возможность дополнительно вложить файлы, в которых пути к зависимостям могут быть указаны в виде файловых путей, URI и даже ссылок на Mercurial- / Git-репозитории (про всё это мы поговорим в следующем параграфе).
В результате мы имеем некоторое количество python-разработчиков, которые считают requirements.txt панацеей от всех проблем. Они даже никогда не узнают о существовании setuptools. Их легко покоряет кажущимся простым тупое перечисление ссылок на необходимые пакеты, лежащие где-то в недрах интернета: на сайтах или в системах контроля версий. Меня обескураживает их святая уверенность в «фантастической» прагматичности этого подхода и вытекающем отсюда желании пропагандировать использование virtualenv+pip как связки незаменимых инструментов для всех и каждого.
URI в качестве путей к зависимостям это отстой
setuptools позволяет вам указать имя и необходимую версию пакета, который по умолчанию скачивается с Pypi. Pypi обеспечивает индексацию, но вы можете создать и свой собственный индекс (в виде простых HTML страниц) и указать, что информацию следует извлекать в первую очередь из них, а не с сайта Pypi. Кто бы ни разработал эту технологию, он пытался предоставить разработчику возможность привязываться к именам пакетов, а не их физическому местоположению или веб-протоколу. И он мыслил правильно.
Что ж, есть другой способ. Давайте указывать зависимости таким способом:
git+https://github.org/my/stupid/fucking/package#egg=1.2.3
Но он требует от пользователя иметь на компьютере git, кроме того pip’у приходится выкачивать полную копию репозитория. А чаще люди и вовсе не используют версионную нотацию (1.2.3 в примере — прим. пер.) и предполагают, что стабильная версия должна лежать в ветке master. Всё это печально. Я знаю, что сейчас модно ставить всё подряд прямо из систем контроля версий, но «хардкордить» эти URL в ваш проект? И без того спорное решение, становящееся совсем неоправданным, если всё можно сделать правильно, просто немного попотев над правильной настройкой setup.py.
Если вам по нраву pip freeze, с вами что-то не так
С другой стороны можно, обнаружив, что эти зависимости порушили вашу среду окружения, попытаться просто пересоздать её. Но с venv+pip это займёт у вас целую вечность (напомню, нужно будет пересобрать всё и вся). В то время как с LXC CoW и уже собранными в бинарные eggs пакетами (всех зависимостей, с которыми вы не работаете в данный момент), вы очень быстро обнаружите недостающие зависимости — как на системном уровне, так и непосредственно питоньи.
В целом pip freeze не такая уж плохая команда, всё дело в том, что люди слишком часто считают её незаменимой, не принимают во внимание её недостатки и используют не по назначению.
Заключение
Это мой критикующий, при этом полностью субъективный и, может, в чём-то даже спорный анализ полезности как программ virtualenv и pip, так и сложившейся вокруг них программерской культуры. Мне очень нравится питон как язык, но меньше — как платформа, потому что она фрагментирована различными стандартами распространения пакетов и стандартами процесса разработки. Лично в моём случае это приводит к тому, что я трачу на борьбу с Питоном больше времени, нежели на работу с ним. Я регулярно общаюсь с разными умными людьми, которые искренне верят, что venv и pip обеспечивают всё, что им нужно для разработки, совместной работы и развёртывания готовых приложений. Я же во время разработки не использую ни venv, ни pip.
И я надеюсь, что эта статья, как минимум, докажет читателю, что можно и нужно понимать принцип работы этих программ и при этом критически относиться к ним.
Менеджер пакетов PIP. Гайд по использованию
P IP — это менеджер пакетов. Он позволяет устанавливать и управлять пакетами на Python.
Представьте себе ситуацию: вы собираете проект и подключаете множество сторонних библиотек для реализации своей задачи. Если это делать вручную, процесс выглядит примерно так:
Вполне вероятно, что эта версия библиотеки вообще не подходит, и весь процесс повторяется заново. А если таких библиотек 10? Устанавливать их вручную?
Если вы работали с другими языками программирования, концепция pip может показаться вам знакомой. Pip похож на npm (в Javascript), composer (в PHP) или gem (в Ruby).
Pip является стандартным менеджером пакетов в Python
Pip или pip3?
В зависимости от того, какая версия Python установлена в системе, может потребоваться использовать pip3 вместо pip.
Если вы не знаете какая версия Python установлена на вашей системе, выполните следующие команды:
Советуем использовать версию Python 3.6 и выше
Если команда «python» не найдена, установите Python по инструкции из предыдущей статьи.
Далее нужно убедиться, что сам PIP установлен и работает корректно. Узнать это поможет команда:
Команда отобразит в консоли версию pip, путь до pip и версию python, для которой в дальнейшем будут устанавливаться пакеты:
pip 19.2.3 from /usr/local/lib/python3.8/site-packages/pip (python 3.8)
Альтернативный вариант вызова pip:
Если pip не установлен
Pip поставляется вместе с Python, и доступен после его установки. Если по какой-то причине pip не установлен на вашей системе, установить его будет не сложно.
Windows:
Linux (Ubuntu и Debian)
Для Питона 2-й версии, выполните команду:
apt-get install python-pip
Для Питона 3-ей версии:
apt-get install python3-pip
MacOS
Должна появиться запись Successfully Installed. Процесс закончен, можно приступать к работе с PIP на MacOS!
Как обновить PIP
Иногда, при установке очередного пакета, можно видеть сообщение о том, что доступна новая версия pip.
WARNING: You are using pip version 19.2.3, however version 19.3.1 is available.
А в следующей за ней строке
указана команда для обновления pip:
Команды PIP
Синтаксис pip выглядит следующим образом: pip + команда + доп. опции
Рассмотрим команды pip:
Пример работы с пакетами
PIP позволяет устанавливать, обновлять и удалять пакеты на компьютере. Ниже попробуем разобраться с работой менеджера pip на примере парсинга названий свежих статей на сайте habr.com.
Для начала, нам необходимо установить beautifulsoup4 — библиотеку для парсинга информации с веб-сайтов.
pip3 install beautifulsoup4
pip3 install beautifulsoup4==4.8.2
Данная команда способна даже перезаписать текущую версию на ту, что вы укажите.
Также для работы beautifulsoup нам понадобится пакет lxml :
☝️ Важный момент : по умолчанию pip устанавливает пакеты глобально. Это может привести к конфликтам между версиями пакетов. На практике, чтобы изолировать пакеты текущего проекта, создают виртуальное окружение (virtualenv).
Шаг #2 Импортирование в скрипте.
Для того чтобы воспользоваться функционалом установленного пакета, подключим его в наш скрипт, и напишем простой парсер:
from urllib.request import urlopen from bs4 import BeautifulSoup # скачиваем html page = urlopen(«https://habr.com/ru/top/») content = page.read() # сохраняем html в виде объекта BeautifulSoup soup = BeautifulSoup(content, «lxml») # Находим все теги «a» с классом «post__title_link» all_a_titles = soup.findAll(«a», < "class" : "post__title_link" >) # Проходим по каждому найденному тегу и выводим на экран название статьи for a_title in all_a_titles: print(a_title.text)
Шаг #3 requirements.txt.
Файл requirements.txt создается командой:
pip freeze > requirements.txt
и выглядит следующим образом:
beautifulsoup4==4.8.2 lxml==4.4.2 soupsieve==1.9.5
Теперь ваш скрипт вместе с файлом requirements.txt можно сохранить в системе контроля версий (например git).
Для работы парсера в новом месте (например на компьютере другого разработчика или на удаленном сервере) необходимо затянуть файлы из системы контроля версий и выполнить команду:
Шаг #4 Обновление/удаление установленных пакетов.
Однако бывают ситуации, когда нужно обновить сразу все пакеты из requirements.txt. Достаточно выполнить команду:
Для удаления пакета выполните:
pip uninstall package-name
Для удаления всех пакетов из requirements.txt:
Мы разобрали основы по работе с PIP. Как правило, этого достаточно для работы с большей частью проектов.