Linux install requirements txt

requirements.txt

В исходниках множества Python-проектов можно встретить этот странный текстовый файл. Например, им пользуются urllib3, numpy, pandas, flake8 и куча других проектов. Давайте разберемся, что это такое, как этим пользоваться и зачем нам это нужно.

Гипотетическая предыстория

Давайте представим, что вы написали замечательный скрипт, который спрашивает у пользователя название города и выводит текущую температуру и общее состояние погоды:

Скрипт получился настолько хорош, что вы хотите поделиться им со всеми своими друзьями. К сожалению, друзья при попытке запустить вашу программу получают следующую ошибку:

Traceback (most recent call last): File "weather.py", line 3, in from pyowm import OWM ModuleNotFoundError: No module named 'pyowm' 

Кажется, что скинуть только код недостаточно.

Или, допустим, что вы сами через полгода-год попытаетесь запустить эту же программу. За это время вы успели пару раз переустановить Python, переустановить ОС, отформатировать свой магнитный накопитель (используйте SSD — нет, я серьёзно!) или может быть вообще сменили компьютер. Почти уверен, что при запуске скрипта вы получите ровно ту же самую ошибку.

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

Если ваша программа небольшая (состоит из пары файлов), то можно довольно легко просмотреть её глазами, найти там все инструкции import , отсеять из них импорты из стандартной библиотеки (вы ведь знаете модули стандартной библиотеки наизусть, да?), и таким образом восстановить список внешних зависимостей программы, которые устанавливаются через pip . Чем крупнее проект, тем сложнее это сделать. Бывают ситуации, когда по коду вообще нельзя понять, что ему нужна определенная зависимость.

Я хочу сказать, что намного мудрее составлять этот список зависимостей сразу же и просто поддерживать его в актуальном состоянии по мере развития проекта.

requirements.txt — это список внешних зависимостей

Сообщество Python исповедует идеологию «простое лучше, чем сложное». Наверное, поэтому для хранения списка зависимостей сообщество выбрало самый простой из возможных форматов — текстовый файл, где на каждой строке перечислено ровно по одной зависимости.

Стоит отметить, что requirements.txt не является стандартом, т.е. нет документа, который описывал бы требования к этому файлу. Скорее, это просто распространённая практика в сообществе, которая, наверное, возникла спонтанно и хорошо прижилась.

Не обязательно называть файл именно requirements.txt , можно назвать его как угодно, лишь бы его назначение оставалось понятно. Я встречал такие вариации, как requirements-dev.txt , test-requirements.txt , requirements/docs.txt и другие.

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

Если бы было несколько зависимостей, то файл выглядел бы так:

Можно указать конкретную версию зависимости. Если версия не указана, то считается, что нужна последняя доступная:

numpy # нужна последняя версия requests==2.23.0 # нужна конкретная версия 

Можно указывать диапазоны и другие более сложные «спецификаторы версий». В целом, в requirements.txt можно писать любые «запросы», которые понимает команда pip install :

Как пользоваться

Команда pip install умеет читать такие файлы, если передать специальный флаг:

$ pip install --help . Install Options: -r, --requirement Install from the given requirements file. This option can be used multiple times. . 

Таким образом, если requirements.txt будет иметь вот такое содержимое:

pytest flake8 black isort 

То следующие две команды будут иметь одинаковое действие:

$ pip install -r requirements.txt $ pip install pytest flake8 black isort 

Преимущества использования requirements.txt :

• Краткость. На таком маленьком примере разница может быть не очевидна, но когда список зависимостей разрастётся до определенного размера, то вам не захочется больше перечислять его в pip install напрямую.
• Стабильность. Как бы ни поменялся файл requirements.txt , команда pip install -r requirements.txt не поменяется.
• Универсальность. Так как это распространённое соглашение, то другим разработчикам будет достаточно увидеть этот файл, чтобы понять, что нужно сделать. Это здорово экономит время на чтении инструкций.

Как создать

Главный принцип ручного подхода — если что-то поменялось в списке зависимостей (добавилась или удалилась зависимость, обновилась версия и т.д.), это изменение нужно отразить в requirements.txt .

Но можно использовать и встроенную в pip функциональность:

(env) $ pip freeze certifi==2020.4.5.1 chardet==3.0.4 geojson==2.5.0 idna==2.9 pyowm==2.10.0 requests==2.23.0 urllib3==1.25.9 

Команда pip freeze выводит все установленные в интерпретатор сторонние пакеты. Заметьте, что в список попали не только прямые зависимости ( pyowm ), но и подзависимости — это даже лучше, потому что вы сможете более точно воссоздать окружение по этому файлу.

Можно перенаправить вывод этой команды в файл при помощи стандартного консольного приема (работает и на Windows), и получить валидный файл requirements.txt :

(env) $ pip freeze > requirements.txt 

Обратите внимание, что pip freeze выведет список пакетов в том окружении, в котором он запущен. Не забудьте активировать виртуальное окружение перед запуском этой команды, иначе получите список пакетов, установленных в глобальный интерпретатор. Кстати, у меня есть пост про виртуальные окружения, где объясняется как ими пользоваться.

Подытожим плюсы и минусы ручного и автоматического подходов:

• Вручную:
  • минимальный файл, содержащий только прямые зависимости;
  • можно указывать сложные спецификаторы версий;
  • человеческий фактор — легко ошибиться или забыть что-нибудь;
  • автоматически, быстро;
  • автоматически добавляет версии установленных пакетов;
  • в файл попадет всё дерево зависимостей, а не только прямые зависимости.

  Можно использовать и смешанный подход: сгенерировать начальную версию файла при помощи pip freeze и допилить её затем руками, если у вас какая-то сложная нестандартная ситуация.

  ⚠️ Файл requirements.txt , конечно же, должен быть добавлен в систему контроля версий (git). Это такая же важная часть проекта, как и код. При этом виртуальное окружение не должно попадать в систему контроля версий. Оно должно воссоздаваться из requirements.txt .

  Проблемы requirements.txt

  Некоторые пакеты часто меняются, поэтому если вы не указываете конкретные версии, то в следующий раз при установке вы можете получить совсем другую среду. Это бывает особенно обидно, когда локально на машине разработчика всё работает правильно, но при деплое на боевой сервер программа либо работает иначе, либо вообще отказывается запускаться. Поэтому обязательно фиксируйте версии пакетов в requirements.txt — это сделает разные окружения хотя бы примерно похожими.

  Почему «хотя бы примерно»? Практика показывает, что зафиксировать версию пакета недостаточно. Иногда случается, что под одной версией пакета в разное время может находиться совершенно разный код. PyPI, конечно, не позволит перезаписать уже опубликованную версию, но, например, ваш приватный корпоративный индекс пакетов может быть не таким строгим.

  Чтобы действительно гарантировать, что вы устанавливаете те пакеты, что и ожидали, нужно рассчитывать и сверять их контрольные суммы. requirements.txt может содержать хэши пакетов, но, к сожалению, на данный момент нет простого стандартного способа как их туда положить, кроме как вручную (сложно). В качестве альтернативы опять предлагаю присмотреться к таким проектам, как poetry (хранит хэши в poetry.lock ) и pipenv (хранит хэши в Pipfile.lock ), где эта проблема решена хорошо, и вам не придётся переживать о воспроизводимости ваших сборок. Если всё-таки хочется добиться такого же эффекта при помощи requirements.txt , то можно посмотреть на такие проекты как pip-tools (пример использования) и hashin .

  Заключение

  requirements.txt — это очень популярный способ хранения списка внешних зависимостей проекта, поэтому вам определенно нужно уметь работать с такими файлами. Однако этот способ хранения списка зависимостей не лишён недостатков, поэтому если вы начинаете новый проект, то я предлагаю вам лучше использовать для этого poetry или pipenv .

  Для тренировки можно попытаться запустить скрипт с погодой. Все исходники лежат здесь.

  Дополнительное чтение

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

  Подпишитесь!

  Чтобы получить уведомление о новом посте можно:

  Источник

  Installing packages using pip and virtual environments¶

  This guide discusses how to install packages using pip and a virtual environment manager: either venv for Python 3 or virtualenv for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs.

  This doc uses the term package to refer to a Distribution Package which is different from an Import Package that which is used to import modules in your Python source code.

  Installing pip¶

  pip is the reference Python package manager. It’s used to install and update packages. You’ll need to make sure you have the latest version of pip installed.

  Debian and most other distributions include a python-pip package; if you want to use the Linux distribution-provided versions of pip, see Installing pip/setuptools/wheel with Linux Package Managers .

  You can also install pip yourself to ensure you have the latest version. It’s recommended to use the system pip to bootstrap a user installation of pip:

  python3 -m pip install --user --upgrade pip python3 -m pip --version

  Afterwards, you should have the latest version of pip installed in your user site:

  pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)

  The Python installers for Windows include pip. You can make sure that pip is up-to-date by running:

  py -m pip install --upgrade pip py -m pip --version

  Afterwards, you should have the latest version of pip:

  pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4)

  Installing virtualenv¶

  If you are using Python 3.3 or newer, the venv module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section.

  virtualenv is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip.

  python3 -m pip install --user virtualenv

  py -m pip install --user virtualenv

  Creating a virtual environment¶

  venv (for Python 3) and virtualenv (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a “virtual” isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications.

  To create a virtual environment, go to your project’s directory and run venv. If you are using Python 2, replace venv with virtualenv in the below commands.

  The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it env .

  venv will create a virtual Python installation in the env folder.

  You should exclude your virtual environment directory from your version control system using .gitignore or similar.

  Activating a virtual environment¶

  Before you can start installing or using packages in your virtual environment you’ll need to activate it. Activating a virtual environment will put the virtual environment-specific python and pip executables into your shell’s PATH .

  You can confirm you’re in the virtual environment by checking the location of your Python interpreter:

  Источник