Исправляем no python application found в uWSGI на PythonAnywhere: проблема в виртуальном окружении

Разбор ошибки no python application found при деплое Django на PythonAnywhere: uWSGI падает из‑за сломанного виртуального окружения (ModuleNotFoundError math).

Перенос Django‑приложения с одного хоста на другой — обычная задача, пока платформа не отвечает «Internal Server Error», а серверный лог не заявляет: «no python application found». Если в том же логе всплывает ещё и ModuleNotFoundError для стандартного модуля вроде math при импорте datetime, это уже не типичная ошибка конфигурации приложения — перед вами сломанное виртуальное окружение.

Контекст

Приложение работает на PythonAnywhere с Python 3.11 и uWSGI. Лог ошибок пуст, а серверный лог описывает следующую цепочку: стартует воркер, uWSGI находит виртуальное окружение, после чего всё падает с трейcбеком внутри стандартного модуля datetime при попытке импортировать math; затем идут сообщения «unable to load app 0 (callable not found or import error)» и знакомое «no python application found». На фронтенде отображается обычная «Internal Server Error».

Минимальный пример

В том же виртуальном окружении даже тривиальный импорт приводит к сбою. Маленький фрагмент демонстрирует проблему:

try:
    import datetime as dt_unit
    print(dt_unit.datetime.utcnow())
except Exception as problem:
    print(type(problem).__name__, str(problem))

Вместо выполнения он поднимает ModuleNotFoundError для math во время импорта стандартного модуля datetime — ровно то, что видно в серверном логе.

Что на самом деле ломается

uWSGI не может загрузить WSGI‑приложение, потому что в настроенном виртуальном окружении срывается импорт стандартной библиотеки Python. Сообщение «unable to load app 0 (callable not found or import error)» об этом и говорит, а «no python application found» — лишь следствие, когда инициализация уже не удалась. Пустой error‑лог этому не противоречит: в серверном логе уже есть критичный трейcбек, который останавливает запуск.

Рабочее решение

Первопричиной оказалось само виртуальное окружение. Пересоздание окружения на той же версии Python давало тот же сбой, а создание на следующей версии сработало. Переключение приложения на новое виртуальное окружение устранило ошибку импорта math и позволило uWSGI загрузить Django‑приложение.

Проверка результата

После перехода на виртуальное окружение с более новой версией Python быстрая проверка показывает, что стандартная библиотека импортируется как положено:

import math as mathlib
from datetime import datetime as when
print("stdlib ok:", mathlib.pi, when.utcnow())

Когда импорты ведут себя нормально, uWSGI инициализируется без проблем, и сообщения «no python application found» исчезают.

Почему это важно

Когда платформа сообщает о типовой ошибке при запуске, легко начать копаться в настройках Django, путях WSGI или PYTHONPATH. Но если в серверном логе виден ModuleNotFoundError для модулей стандартной библиотеки, проблема лежит ниже уровня вашего приложения — в виртуальном окружении. Умение распознать этот признак экономит часы бесплодной отладки.

Практические выводы

Начните с серверного лога: в такой ситуации там уже есть ключевой трейcбек. Если сбой воспроизводится минимальным импортом в том же виртуальном окружении, относитесь к нему как к подозрительному. Пересоберите окружение, а если на той же версии Python оно всё ещё ведёт себя неправильно, перенесите приложение в виртуальное окружение, созданное на следующей доступной версии Python. Именно этот шаг здесь и помог.

Здоровое виртуальное окружение — базовое условие любого развёртывания Django. Если падают импорты из стандартной библиотеки, сначала приводите в порядок окружение — остальной стек подтянется.