requirements.txt — что это и зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На таком маленьком примере разница может быть не очевидна, но когда список зависимостей разрастётся до определенного размера, то вам не захочется больше перечислять его в pip install напрямую.

Как бы ни поменялся файл requirements.txt , команда pip install -r requirements.txt не поменяется.

Так как это распространённое соглашение, то другим разработчикам будет достаточно увидеть этот файл, чтобы понять, что нужно сделать. Это здорово экономит время на чтении инструкций.

Как создать

Есть два подхода:

• создавать этот файл вручную;
• генерировать автоматически.

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

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

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

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

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

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

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

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

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

Pip freeze requirements txt windows

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

Читайте про if __name__ == ‘__main__’ , констркуцию, присутствующую почти в каждом Python модуле

Requirements.txt — как получить?

Как получить requirements.txt, имея django проект?

7 ответов 7

С помощью команды:

Чтобы получить список пакетов в проекте выполняем команду

Для записи вывода в requirements.txt дополняем следующим образом:

Команду выполняем в корне проекта. Там же появится и файл. Подразумевается использование активного venv для текущего проекта. При выполнении вне виртуальной среды текущего проекта могут быть подтянуты лишние пакеты, не связанные с текущим проектом!

Лучше всего смотреть в INSTALLED_APPS и выковыривать всё вручную. С pip freeze есть вариант получить тыкву через некоторое время, ибо он вытягивает абсолютно все пакеты вместе с их зависимостями (включая системные), а пакеты со временем обновляются, старые версии удаляются. Да и нечего вам рулить зависимостями вручную — это задача менеджера пакетов (pip или easy_install).

Лучше всего заполнять файл requirements по мере написания проекта, а не после.

Добавлено: Есть подходящая опция у pip: pip freeze —local .

Из справки: If in a virtualenv that has global access, do not output globally-installed packages.

Чтобы создать requirements.txt или обновить уже существующий файл, чтобы он соответствовал текущему virtualenv, можно использовать pip-dump команду:

Для работы с requirements.txt есть Python библиотека pipreqs

Установка: pip install pipreqs

• Чтобы сгенерировать файл requirements.txt используйте pipreqs /path/to/project/folder
• Если requirements.txt уже есть и необходимо его перезаписать, то используйте флаг —force
• Если нужно просто посмотреть на используемые библиотеки без создания, флаг —print

Чет сначала прочел по-русски а отвечать начал по-английски. Ну так вот, немного магии если нет venv

If you have little project THIS will do some magic

for i in `cat *.py | grep -R import | sort | uniq | sed ‘s/^import//; s/^from//; s/ import.*//’`; do python -m pip freeze —local | grep -i $i; done

You should check it, but it work. Проходит по всем файлам, собирает импорты и грепает по установленным пакетам, естественно не ищет полное соответствие, поэтому будут лишние, но не много.

pip freeze > requirements.txt including all system installed packages inside virtualenv

Bit of backstory, I’m relatively new to Python and development in general and have stupidly been installing project specific packages as system packages. This is now causing me issues when trying to create requirements.txt files for specific projects, inside of virtualenvs.

For example, I’ve installed Kivy system wide and every time I create a new env with a requirements file I’m getting the below (yes the env is active):

I’ve also tried uninstalling Kivy, amongst other things (trying to be cautious here, don’t want to remove vital OS packages) but get the following output:

So my questions is this: How can I get my python packages back to default, with only the essential system packages installed (almost like a fresh python install), then how do I prevent the requirements.txt files inside of a virtualenv including the system wide installed packages (I’ll be using evn’s much better in future so shouldn’t have too many system wide packages)

I’d also be interested to find out why pip unistall kivy doesnt work (yes, I’ve tried running this as root also)

Running Debian 8, if that makes any difference

Hope this makes sense and appreciate any advise you may have.

EDIT: So I think I’ve been doing this whole thing wrong, once I’ve created the env I’ve been using pip install rather than env/bin/pip install . Unless I’m mistaken this is why the packages have been installing globally. Same goes for the requirements file.

How can I install packages using pip according to the requirements.txt file from a local directory?

Here is the problem:

I have a requirements.txt file that looks like:

I have a local archive directory containing all the packages + others.

I have created a new virtualenv with

Upon activating it, I tried to install the packages according to requirements.txt from the local archive directory.

I got some output that seems to indicate that the installation is fine:

But a later check revealed none of the package is installed properly. I cannot import the package, and none is found in the site-packages directory of my virtualenv. So what went wrong?

12 Answers 12

This works for me:

—no-index — Ignore package index (only looking at —find-links URLs instead).

-f, —find-links — If a URL or path to an HTML file, then parse for links to archives.

If a local path or file:// URL that’s a directory, then look for archives in the directory listing.

This works for everyone:

For virtualenv to install all files in the requirements.txt file.

1. cd to the directory where requirements.txt is located
2. activate your virtualenv
3. run: pip install -r requirements.txt in your shell

I had a similar problem. I tried this:

(-U = update if it had already installed)

But the problem continued. I realized that some of generic libraries for development were missed.

I don’t know if this would help you.

For further details, please check the help option:

We can find the option ‘-r’ —

-r, —requirement Install from the given requirements file. This option can be used multiple times.

Further information on some commonly used pip install options (this is the help option on the pip install command):

Also the above is the complete set of options. Please use pip install —help for the complete list of options.

Short answer

or in another form:

Explanation

Here, -r is short form of —requirement and it asks the pip to install from the given requirements file.

pip will start installation only after checking the availability of all listed items in the requirements file and it won’t start installation even if one requirement is unavailable.

One workaround to install the available packages is installing listed packages one by one. Use the following command for that. A red color warning will be shown to notify you about the unavailable packages.

To ignore comments (lines starting with a # ) and blank lines, use:

Often, you will want a fast install from local archives, without probing PyPI.

First, download the archives that fulfill your requirements:

Then, install using –find-links and –no-index :

First of all, create a virtual environment.

Then activate the environment and install all the packages available in the requirement.txt file.

/Scripts/activate.bat . To deactivate environment, use this :

/Scripts/deactivate.bat . – fendiSetiawan Oct 16 ’20 at 4:00

I work with a lot of systems that have been mucked by developers «following directions they found on the Internet». It is extremely common that your pip and your python are not looking at the same paths/site-packages. For this reason, when I encounter oddness I start by doing this:

That is a happy system.

Below is an unhappy system. (Or at least it’s a blissfully ignorant system that causes others to be unhappy.)

It is unhappy because pip is (python3.6 and) using /usr/local/lib/python3.6/site-packages while python is (python2.7 and) using /usr/local/lib/python2.7/site-packages

When I want to make sure I’m installing requirements to the right python, I do this:

You’ve heard, «If it ain’t broke, don’t try to fix it.» The DevOps version of that is, «If you didn’t break it and you can work around it, don’t try to fix it.»