Если что-то не работает
Ошибка при установке requirements.txt: почему падает сборка
Коротко
Ошибка при установке requirements.txt почти всегда вызвана самим файлом, а не хостингом. Причина номер один — файл сделан командой pip freeze, и в него попали строки с путями к папкам вашего компьютера (вида @ file:///) и пакеты, которых нет в открытом индексе. Дальше по частоте идут закреплённая версия, которой не существует для той версии Python, на которой идёт сборка, пакеты только для Windows и посторонние символы в файле. Лечение одно: переписать requirements.txt руками, оставив только те библиотеки, которые проект действительно импортирует, и убрать лишние закрепления версий.
Ошибка при установке requirements.txt выглядит одинаково пугающе на любом хостинге: длинная простыня текста, где-то в середине строка could not find a version that satisfies the requirement, и сборка останавливается. Хорошая новость в том, что виновата обычно не платформа и даже не ваш код, а сам список библиотек: чаще всего его сделали автоматически, и в него попало лишнее.
Обычно такую ошибку разбирают вслепую: заходят на сервер, ставят пакеты руками, пробуют снова, ловят момент, когда всё встало. В Netrun логи сборки видны в кабинете в реальном времени, и в них написано, на каком пакете и на какой строке всё остановилось, — дальше дело в одной-двух правках файла. Ниже причины по частоте: от самой популярной до редкой, и что делать с каждой.
Прочитайте логи сборки и найдите имя пакета#
Не читайте весь вывод целиком — смотрите последние строки перед остановкой. Там почти всегда написано имя пакета и номер строки в requirements.txt: например, could not find a version that satisfies the requirement и дальше название библиотеки. Логи сборки обычно можно открыть прямо у хостинга, где вы публикуете проект, — начните с них, а не с догадок по коду. Имя пакета из этой строки и есть ваш диагноз.
Уберите строки с путями к вашему компьютеру#
Если файл сделан командой pip freeze, в нём часто оказываются строки вида имя-пакета @ file:///Users/... или @ file:///C:/... — это ссылки на папки на вашей машине. На сервере таких папок нет, и установка падает сразу. Удалите из такой строки всё, что идёт после символа @, оставив только имя пакета, а если пакет вам не нужен — удалите строку целиком. Это причина номер один у всех, кто получил файл автоматически.
Соберите requirements.txt заново — по импортам, а не через freeze#
Команда pip freeze выгружает всё, что стоит в окружении: инструменты разработки, зависимости зависимостей, случайно поставленные библиотеки и системные пакеты, которых в открытом индексе нет вообще. Надёжнее написать файл руками: пройдитесь по своим файлам с кодом, выпишите то, что реально импортируется — requests, flask, aiogram, — и оставьте только это. Список из пяти строк ставится быстрее и ломается реже, чем список из двухсот. Виртуальное окружение, папку venv, в архив класть не нужно: библиотеки ставятся при сборке.
Снимите закрепления версий, которых не существует#
Строка вида пакет==1.2.3 требует ровно этой версии. Если такой версии нет для той версии Python, на которой идёт сборка, или её убрали из индекса, вы увидите то самое could not find a version that satisfies the requirement, а рядом обычно печатается список версий, которые есть на самом деле. Уберите номер версии у проблемного пакета или возьмите версию из этого списка. Так же лечатся несовместимые закрепления, когда две библиотеки требуют разных версий третьей: снимите жёсткие версии там, где они вам не принципиальны.
Уберите пакеты только для Windows и тяжёлые сборки#
Библиотеки pywin32, pypiwin32, windows-curses и им подобные существуют только под Windows и на сервере с Linux не поставятся никогда. В коде они обычно не используются и попали в файл всё тем же freeze — удаляйте смело. Отдельный случай — пакеты, которые собираются из исходников и требуют системных библиотек: часто помогает не закреплять версию, потому что у свежих версий есть готовые сборки под Linux, или взять библиотеку попроще. Если пакет нужен именно такой, положите рядом с кодом свой Dockerfile, который ставит нужные системные библиотеки, — Netrun возьмёт его вместо автоматической сборки.
Проверьте файл на посторонние символы и загрузите новую версию#
Файл должен быть простым текстом: одна библиотека на строку, без кириллицы, без пояснений на русском в конце строки, без кавычек и лишних пробелов. Часто всё ломает копирование из чата или из статьи: вместо обычного дефиса приезжает длинное тире, вместо пробела — неразрывный, а редактор дописывает свою кодировку. Сохраните файл обычным текстовым редактором в кодировке UTF-8, загрузите новую версию проекта и смотрите логи. Если сборка снова упала, у вас уже есть следующее имя пакета, и круг повторяется на одну строку короче.
Главное, что стоит знать, пока вы это чините: неудачная сборка ничего не удаляет. Код, настройки и секреты остаются на месте, а исправленную версию можно загрузить заново — столько раз, сколько потребуется. В Netrun логи каждой попытки видны в кабинете в реальном времени, так что сразу понятно, сдвинулась ли ошибка на следующий пакет или осталась на том же. Попробовать Netrun.
Частые вопросы
Что означает ошибка could not find a version that satisfies the requirement?
Это значит, что установщик сходил в индекс пакетов и не нашёл там ни одной версии, подходящей под вашу строку. Чаще всего дело в закреплённой версии, которой не существует для той версии Python, на которой идёт сборка, либо в опечатке в названии пакета. Рядом с ошибкой обычно печатается список версий, которые есть на самом деле, — возьмите версию оттуда или уберите закрепление совсем.
Почему на моём компьютере всё ставится, а при публикации падает?
На вашей машине часть библиотек уже стоит с прошлых проектов, поэтому установщик их не трогает и ошибку вы не видите. На сервере окружение чистое: ставится ровно то, что перечислено в файле, и любая неверная строка останавливает сборку. Кроме того, версия Python и операционная система при сборке могут отличаться от ваших — часть пакетов из вашего окружения там просто не существует.
Нужно ли закреплять версии пакетов в requirements.txt?
Закреплять полезно, когда проект живёт долго и вам важна повторяемость, но закреплять всё подряд выгрузкой из pip freeze вредно. Практичный компромисс: зафиксируйте одну-две библиотеки, где версия для вас критична, а остальные оставьте без номера. Тогда сборка не будет падать из-за версии пакета, которым вы даже не пользуетесь.
Что делать, если пакет требует компиляции и системных библиотек?
Сначала попробуйте не закреплять версию: у свежих версий популярных библиотек обычно есть готовые сборки под Linux, и компилировать ничего не придётся. Если системные библиотеки всё равно нужны, положите в проект свой Dockerfile, который их устанавливает, — платформа возьмёт его вместо автоматической сборки. Иногда проще заменить библиотеку на более лёгкую: например, разбирать HTML без браузера.
Что происходит с проектом, если новая сборка упала?
Ничего не удаляется: код, настройки и секреты остаются на месте, а новая версия просто не применяется, пока не соберётся. В кабинете видно, что публикация не удалась и на каком пакете всё остановилось. Исправленный requirements.txt можно загрузить заново столько раз, сколько нужно.
Что делать, если requirements.txt вообще нет?
Создайте его сами: обычный текстовый файл в корне проекта, по одной библиотеке на строку. Впишите туда только то, что ваш код импортирует, — без стандартных модулей Python вроде os, json или datetime, они уже есть. Без этого файла зависимости ставить неоткуда, и проект упадёт уже при запуске с сообщением, что модуль не найден.
Можно ли запустить проект на Python — Django, Flask или FastAPI?
Да. Положите зависимости в requirements.txt — Netrun определит Python и соберёт проект сам. Django, Flask и FastAPI поддерживаются; приложение должно слушать порт из переменной окружения, а ключи и доступ к базе задаются как секреты, а не в коде.
Где посмотреть логи и статус проекта?
На странице проекта есть статус, логи и история событий — по ним видно, что происходит с проектом прямо сейчас. Лента логов показывает и более ранние строки: пролистайте её вверх, и они подгрузятся сами.
Как обновить код уже опубликованного проекта?
Откройте проект и загрузите новую версию или обновите его из GitHub. Ссылка останется прежней, а данные сохранятся, если лежат в постоянном хранилище — папке /data или томе вашего compose-файла.