Requirements txt что это
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, конечно, не позволит перезаписать уже опубликованную версию, но, например, ваш приватный корпоративный индекс пакетов может быть не таким строгим.
Заключение
Для тренировки можно попытаться запустить скрипт с погодой. Все исходники лежат здесь.
Дополнительное чтение
Подпишитесь!
Чтобы получить уведомление о новом посте можно:
Все требования в одном месте – requirements.txt
Обычно для запуска проекта требуется несколько внешних пакетов.
Чтобы каждый раз с болью в сердце не собирать их, список этих пакетов принято поставлять вместе с исходным кодом. Принято селить весь список необходимых пакетов в файле requirements.txt в корне проекта. Формат этого файла простой: по одному пакету на строку.
Заморозка пакетов
У одного пакета обычно много версий. Когда мы просим пип установить пакет, он устанавливает самую свежую из доступных.
Это может привести к проблемам: скажем, проект разрабатывался на версии 1.2. Через полгода потребовалось развернуть его заново, пип установил последнюю версию – 1.5. Эта версия может быть не совместима со старой, тогда код сломается.
Вот часть requirements.txt из Девмана:
Получить все версии пакетов, установленных на вашем компьютере, можно командой pip freeze :
Все зависимости заморозить и в requirements.txt
Установка
Зависимости зависимостей
К сожалению, правильное заполнение requirements.txt не решает все проблемы с зависимостями и версиями.
Эта проблема свойственна большим проектам, у которых десятки зависимостей и сотни неявных зависимостей.
Решение этой проблемы рассмотрим в другой раз. Главное – быть начеку.
Попробуйте бесплатные уроки по Python
Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.
Переходите на страницу учебных модулей «Девмана» и выбирайте тему.
Мелкая питонячая радость #3: Poetry
Управление зависимостями? Шо, опять?
Экосистема Python породила целую пачку способов управления зависимостями в проектах.
Прямо сейчас можно выбирать между setup.py, requirements.txt, setup.cfg, MANIFEST.in и Pipfile.
Но французского питониста Sébastien Eustace все эти способы не устроили, и он написал свою штуку для менеджмента питонячих пакетов — Poetry. Зачем он это сделал? Чтобы заменить все эти setup.py, requirements.txt, setup.cfg, MANIFEST.in и Pipfile чем-то простым и понятным. Плюс добавить кое-что полезное сверху.
Poetry позволяет рулить сразу кучей вещей — версией языка в вашем проекте, зависимостями, подключаемыми путями, скриптами тестирования/разработки, сборкой и публикацией билдов.Все необходимые пути, зависимости и скрипты описываются в специальном файле pyproject.toml.
Poetry лучше всего работает в паре с pyenv — системой управления множественными версиями Python и виртуальными окружениями.
Щупаем
Засучим рукава и посмотрим, как poetry работает в деле. Первым делом ставим pyenv, следуя официальной инструкции в доках.
Среда установлена и настроена, зависимости управляются одним пальцем, можно пилить код!
У вас, скорее всего, появятся в проекте команды запуска сервера, воркеров, скриптов деплоя и тестирования. Их можно засунуть в pyproject.toml и тоже рулить ими одним пальцем.
и теперь можно запускать скрипт командой
Зачем это все?
Потратив десяток минут на освоение этой штуки, вы сэкономите время и нервы на управлении версиями языка и пакетов, отслеживании зависимостей и настройке путей. Особенно это поможет тем, кто хоть раз пробовал опубликовать свои наработки в pip 🙂
Poetry прекасно дружит с другими управлялками виртуальными средами, так что интегрировать новый подход в старые проекты будет очень легко.
Python requirements.txt. Создание и применение
Итак requirements.txt! Это питоновский аналог package.json. если кто знаком с node js.
Эта штука нужна при деплое (заливании проекта на сервер), а также при командной разработке, чтобы одной командой установить все используемые в проекте библиотеки правильных версий.
1) создание виртуального окружения: virtualenv venv
2) активация виртуального окружения:
3) эти команды нужно выполнить, если не работает pip freeze в пункте 4.
linux: sudo apt-get install python-matplotlib
4) Чтобы сформировать вышеоговренный файл вводим
pip freeze > requirements.txt
5) чтобы установить библиотеки из сформированного файла в пункте 4:
Ничего сложного, но надо знать.
Кстати в течение недели, как выложил видео в youtube, был на собеседовании, в котором один из вопросов был, «Что такое виртуальное окружение», а об этом я рассказывал в предыдущем видео и сразу представил это:
Следущий вопрос был как раз про requirements.txt. И тут мне было еще тяжелее сдержать улыбку =) Так что будет полезно.
Видео само собой прикладываю.
Бесплатно помогаю пикабушникам учить программирование, часть 24: «Мы составили план обучения фронтенду»
Пикабушника @pt1zza, которая любезно согласилась помогать мне в обучении программированию, составила план обучения по фронтенду. Посмотреть его можно здесь: https://telegra.ph/Roadmap-nachinayushchego-frontend-razrabotchika-11-28
Также мы сделали отдельный telegram-чат, в котором бесплатно помогаем изучить фронтенд-разработку.
Бесплатно помогаю пикабушникам учить программирование, часть 23: «Как сохранять спокойствие и не выгорать.»
Я продолжаю отвечать на вопросы из комментариев своих подписчиков. Задавая их вы помогаете проекту развиваться. Началось всё здесь
Нижеописанные советы основаны исключительно на личном опыте.
1. Не работайте сверхурочно.
Этим очень часто грешат на галерах в аутсорсе. Некоторые «эффективные менеджеры» могут позвонить в субботу утром потому, что образовалась ну очень срочная задача, которую совсем никак нельзя откладывать. Доверительно относиться к таким ситуациям не стоит.
В таких случаях никого не волнует ваше состояние. Крайне неразумно разменивать свою вовлеченность в программирование на полное отвращение даже к самым интересным задачам из-за таких персонажей.
2. При малейших признаках выгорания отдыхайте до того, как устали.
3. Общайтесь с кем-то вне работы на нерабочие темы.
4. Освобождайте долговременную память записывая запланированные задачи.
Это очень помогает снизить утомляемость.
5. Ставьте свой комфорт в приоритет.
Всегда помните: работодателей очень много, а такой красивый(вая) вы у мамы один(одна).
6. Не бойтесь новых технологий.
Сейчас рынок разработки очень быстро меняется. Нужно учиться новому почти каждый день, чтобы оставаться на плаву. Если не следит за трендами, то в итоге вы не только невзлюбите свою работу, но и просто останетесь без неё!
7. Фиксируйте все то, что с вами происходит.
Ведите краткий список всех событий, происходивших на вашей работе, которые показались вам значимыми. Память очень ненадежна потому, что она часто притупляет негативный и травмирующий опыт.
Мой канал в Telegram, где я помогаю новичкам: https://t.me/LearnRubyForPikabu
Уже 37 моих подписчиков дошли до получения работы.
Добро пожаловать всем желающим.
Бесплатно помогаю пикабушникам учить программирование, часть 22: «Мы расширяемся, теперь мы идем во Frontend»
Сегодня у нас очень хорошая новость: теперь мы помогаем новичкам которые изучают фронтенд.
Неделю назад в комментариях мне предложили помощь в обучении новичков.
Теперь в нашем telegram-чате можно получить консультацию и по этой теме. Все, по прежнему, бесплатно. Давайте вместе пожелаем Виктории адекватных и легко обучаемых учеников.
Мой канал в Telegram, где я помогаю новичкам: https://t.me/LearnRubyForPikabu
Уже 37 моих подписчиков дошли до получения работы.
Добро пожаловать всем желающим.
Легла в направлении мечты. Пост №3
Всем привет, прошла еще одна неделя. Чем могу поделиться, начала изучать классы, методы и т.д. Кто-то в прошлый раз писал: что там изучать? Мое мнение что есть что, даже не в том плане изучать, а закреплять материал, решала задачи в этом плане и … Вообще решая задачи я поняла, что чувствую себя, как будто нахожусь на эмоциональных качелях, где с одной стороны: “Ух как весело, это было не сложно”, а на другой “Боги, какая же я тупенькая” и на втором варианте эти качели чаще задерживаются. Потом ты эту задачу решаешь и опять думаешь, как же это все не сложно, переходишь к другой и все по новой. Хотя мне от этого больше смешно над собой 😊.
В прошлый раз со мной поделились сайтом https://ulearn.me/ отличный сайт. В дополнении к Udemy очень помогает. Спасибо за совет. К книге почти не прикасалась, так как все что там написано, рассказывается или на одном, или на другом ресурсе.
Так же в комментариях посоветовали почитать Рихтера, я так понимаю, что эту книгу: Программирование на платформе Microsoft.NET Framework 4.5 на языке C#. Вроде бы по отзывам пишут, что хорошая книга, но не совсем для новичков. Так что пока отправится на полку ждать своей очереди.
По поводу книг, если кто-то хочет изучать С# по книге и с нуля. То Джон Пол Мюллер «C# для чайников» в этом плане очень хороша. Но для себя я поняла, что курсы для меня более в приоритете.
Следующую неделю посвящу опять же C#, да может я иду не семимильными шагами, а помедленнее, но для меня главное уяснить материал по-хорошему.
Кстати, вчера играли в настолку «Шерлок Холмс» и у трупа в кармане мы нашли зашифрованную записку, там был не сложный шифр цезаря, но время он все же занял изрядно. И я подумала, а почему бы не сделать программку с этим шифром. Вроде должно получиться и для практики не плохо будет, ну и в будущем в играх пригодится, так как в детективы мы играем часто. P.S. я знаю, что они есть онлайн, но хочется попробовать самой.
Следующая неделя уже будет точно последняя, где я изучаю один С#, далее будет уже с Unity. Поэтому думаю в следующем посте я поделюсь всеми ссылками, книгами, различной литературой которой со мной делились люди в комментариях, что бы это было в одном месте. Плюс добавлю свои.
Спасибо всем, кто помогает. Пока мне очень нравится вся эта тема и останавливаться точно не собираюсь. Кто еще думает стоит начать или не стоит? Однозначно стоит! Даже если не получится, вы будете знать, что попытались, а я уверена, что получится у всех, просто у кого-то займет больше времени, а у кого-то меньше.
Что-то я расписалась, а ведь раньше с трудом пару предложений могла написать, несмотря на всю мою любовь к книгам.
Всем приятной пятницы, отличных выходных и лёгкой следующей недели. Увидимся уже в декабре.
Улучшение Python-кода: 12 советов для начинающих
В мои обязанности входит наём Python-разработчиков. Если у заинтересовавшего меня специалиста есть GitHub-аккаунт — я туда загляну. Все так делают. Может быть, вы этого и не знаете, но ваш домашний проект, не набравший ни одной GitHub-звезды, может помочь вам в получении работы.
То же самое относится и к тестовым задачам, выдаваемым кандидатам на должность программиста. Как известно, мы, когда впервые видим человека, формируем первое впечатление о нём за 30 секунд. Это влияет на то, как мы будем, в дальнейшем, оценивать этого человека. Мне кажется несправедливым то, что люди, обладающие привлекательной внешностью, добиваются всего легче, чем все остальные. То же самое применимо и к коду. Некто смотрит на чей-то проект и что-то тут же бросается ему в глаза. Ошмётки старого кода в репозитории — это как крошки хлеба, застрявшие в бороде после завтрака. Они могут напрочь испортить первое впечатление. Может, бороды у вас и нет, но, думаю, вам и так всё ясно.
Обычно легко понять то, что некий код написан новичком. В этом материале я дам вам несколько советов о том, как обыграть кадровиков вроде меня и повысить свои шансы на получение приглашения на собеседование. При этом вас не должна мучить мысль о том, что, применяя эти советы, вы кого-то обманываете. Вы не делаете ничего дурного. Применяя те небольшие улучшения кода, о которых пойдёт речь, вы не только повышаете свои шансы на успешное прохождение собеседования, но и растёте как программист. Не могу сказать, что профессиональному росту способствует упор на заучивание алгоритмов или модулей стандартной библиотеки.
В чём разница между новичком и более опытным разработчиком? Новичок не работал с устаревшими кодовыми базами. Поэтому он не видит ценности в том, чтобы вкладывать время в написание кода, который легко поддерживать. Часто новички работают в одиночку. Они, в результате, не особенно заботятся о читабельности кода.
Ваша цель заключается в том, чтобы показать то, что вас заботит читабельность вашего кода и возможность его поддержки в будущем.
Поговорим о том, как повысить качество ваших Python-проектов. Советы, которыми я хочу поделиться, улучшат ваш код. А если вы не сделаете из них карго-культ, то они ещё и помогут вашему профессиональному росту.
1. Уберите из репозитория ненужные файлы
▍Примеры
2. Не храните в коде секретные данные
В репозитории не должно быть никаких паролей к базам данных, ключей к внешним API, секретных ключей систем шифрования! Подобные вещи надо хранить в конфигурационных файлах или в переменных окружения. Ещё один вариант — их чтение из защищённого хранилища. А включать их в код — это в высшей степени неправильно. Вот — отличное руководство на тему хранения конфигурационных данных, подготовленное в рамках проекта The Twelve-Factor App (другие материалы этого проекта тоже весьма полезны).
▍Примеры
Неправильно: реквизиты базы данных хранятся в коде
Ниже приведён фрагмент Flask-приложения. Автор хранит реквизиты для доступа к базе данных в коде.
Правильно: реквизиты хранятся в переменных окружения
Перенести реквизиты для доступа к базе данных в переменные окружения совсем несложно:
Теперь нужно, перед запуском приложения, инициализировать переменные окружения:
Вот как работать с этим файлом из кода:
3. Добавьте в репозиторий файл README
▍Примеры
Файл README для Python-проекта
4. Если вы используете сторонние библиотеки — добавьте в репозиторий файл requirements.txt
▍Примеры
Файл requirements.txt для Flask-приложения
Добавление файла requirements.txt в корневую директорию проекта — это самый лёгкий способ отслеживания зависимостей. Можно, помимо сведений о самих зависимостях, дать сведения и об их версиях. Вот пример файла requirements.txt :
Указание более подробных сведений о зависимостях с использованием файла requirements.in
Как видите, готовый файл содержит сведения о точных версиях всех зависимостей.
5. Форматируйте код с помощью black
Неоднородное форматирование кода не помешает ему нормально работать. Но если код хорошо отформатирован — это улучшит его читабельность и упростит его поддержку. Форматирование кода может и должно быть автоматизировано. Если вы пользуетесь VS Code, то можете увидеть рекомендацию по установке black в качестве автоматического средства форматирования исходного кода, написанного на Python. Форматирование кода производится при сохранении файлов. Кроме того, black можно установить самостоятельно и форматировать код, пользуясь средствами командной строки.
▍Примеры
Неправильно: неформатированный код
Код, приведённый ниже, тяжело читать и расширять.
Правильно: тот же самый код, отформатированный с помощью black
Применение black гарантирует то, что переформатированный код будет работать так же, как его исходный вариант. Данный инструмент всего лишь снимает с программиста нагрузку по ручному форматированию кода.
6. Избавьтесь от ненужных команд импорта
Ненужные команды импорта обычно остаются в коде после каких-нибудь экспериментов и после рефакторинга. Если в программе не используется некий модуль, который раньше в ней применялся, не забудьте убрать из кода соответствующую команду импорта. Обычно редакторы подсвечивают неиспользуемые команды импорта, что облегчает их поиск и борьбу с ними.
▍Примеры
Неправильно: наличие в коде ненужных команд импорта
В этом фрагменте кода импортированный модуль os не используется:
Правильно: в коде нет ненужных команд импорта
Вышеприведённый код очень просто привести в приличный вид:
7. Избавьтесь от ненужных переменных
То, о чём говорилось в предыдущем пункте, относится и к неиспользуемым переменным. Они могут попасть в код в те моменты, когда программист создаёт их, думая, что они могут пригодиться в дальнейшем, а потом оказывается, что они не нужны.
▍Примеры
Неправильно: наличие в коде ненужной переменной:
Здесь переменная response не используется:
Правильно: в коде нет ненужных переменных
Тут нет ничего лишнего:
8. Следуйте соглашению по именованию сущностей из PEP 8
Именование сущностей — это как форматирование. Неудачный выбор имён не помешает правильной работе программы, но затруднит работу с кодом. Кроме того, единообразный подход к именованию сущностей снимает с программиста нагрузку, связанную с постоянным выдумыванием имён. Почитать PEP 8 можно здесь.
▍Примеры
Правила именования сущностей из PEP 8
Пример применения PEP 8
Ниже приведён фрагмент кода, имеющего достаточно сложную структуру, но соответствующего правилам PEP 8. Тут я, чтобы продемонстрировать именование разных сущностей, поместил простую функцию в класс.
9. Проверяйте код с использованием линтера
Линтер анализирует код и ищет в нём ошибки, которые можно обнаружить автоматически. Перед отправкой изменений в репозиторий код всегда полезно проверять с помощью линтера.
Различные IDE и редакторы кода, вроде pycharm и VS Code, содержат встроенные линтеры и подсвечивают проблемные участки кода. Программист сам принимает решение о том, следовать этим рекомендациям или нет. Поначалу сообщения об ошибках, выдаваемые линтерами, могут показаться непонятными. Для того чтобы в них ориентироваться, стоит уделить некоторое время изучению используемого линтера. Это себя окупит.
Если говорить о линтерах, представленных инструментами командной строки, то в этой сфере я порекомендовал бы flake8. Этот линтер обладает разумными настройками, применяемыми по умолчанию. Обычно ошибки, о которых он сообщает, стоит исправлять. Если вы хотите строже относиться к своему коду — взгляните на pylint. Этот линтер способен выявлять множество ошибок, в число которых входят и те, о которых мы тут не говорим.
▍Примеры
Файл, который нужно почистить
В нижеприведённом коде (файл ping.py ) можно увидеть некоторые проблемы и без применения линтера.
Результаты анализа кода с помощью flake8
Результаты анализа кода с помощью pylint
10. Удалите из кода команды print, используемые при отладке
▍Примеры
Неправильно: отладочные команды print в коде
Правильно: код без ненужных команд print
Если убрать из кода отладочные команды — это уменьшит размер функции и повысит удобство работы с ней. А это всегда хорошо.
11. Не держите в репозитории закомментированный код
Очищайте репозиторий от закомментированных старых версий кода и от закомментированного кода, который был написан для проведения каких-нибудь экспериментов. Если вы когда-нибудь решите вернуться к старой версии программы — это всегда можно сделать с помощью инструментов применяемой вами системы контроля версий. Остатки старого кода сбивают с толку тех, кто читает тексты программ. Такой код создаёт впечатление небрежного отношения к нему его автора.
▍Примеры
Неправильно: ненужные комментарии в коде
Автор экспериментировал, прямо в коде программы, с преобразованием строк. Решено было не включать результаты этих экспериментов в итоговый вариант программы, но, на всякий случай, соответствующий код не удалили полностью, а лишь закомментировали.
Правильно: код, в котором нет ненужных комментариев
Обратите внимание на то, насколько легче читать предыдущий код, из которого убраны ненужные комментарии.
12. Оформляйте скрипты в виде функций
▍Примеры
Неправильно: скрипт, не оформленный в виде функции
Выполнение кода в этом примере начинается в первой строке и заканчивается в последней. Такой подход оправдан в том случае, если речь идёт о простых скриптах. Но если код скрипта окажется сложнее, воспринять его будет уже не так легко.
Правильно: скрипт, оформленный в виде функции
Домашнее задание
Говорят, что мы запоминаем лишь 10% того, что прочли. Это значит, что вы запомните лишь один из 12 данных мной советов. Полагаю, это означает, что вы впустую потратили время, читая эту статью. А я, в таком случае, зря её писал.
Но, к счастью, есть одна хитрость. Известно, что практика позволяет сохранить около 80% знаний. Следовательно — вот вам задание: возьмите один из своих проектов и проанализируйте его с точки зрения моих 12 советов. У того, кто так и сделает, в 8 раз больше шансов профессионально вырасти, чем у того, кто просто прочтёт статью.
Есть ли в ваших Python-проектах недочёты, о которых говорит автор этой статьи?