Моя первая разработка на django – система поиска производителей сетевых адаптеров по MAC-адресам: mac.dil.pp.ru .
А некоторое время назад сайт почему-то перестал работать, выдавал ошибку

uWSGI Error
Python application not found

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

Traceback (most recent call last):
  File "./mac/wsgi.py", line 10, in 
    import os
ImportError: No module named os

Потому веб-сервер и не мог прицепиться к этому неазпускающемуся приложению:

unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***

Запустил питон в консоли, там import os нормально работает. Запустил программу через джанговский manage.py runserver – тоже работает, а в uwsgi почему-то нет..

Почти неделю копался, но толком не мог понять, отчего же стандартный питоновый модуль может не импортироваться.

Ну, похоже, что uwsgi пытался использовать старый python 2.6, а он уже проапдейтился до 2.7. Так что грабельки удалось обойти, вписав в uwsgi’шный ini-файл plugin = python27. Теперь вроде нормально работает.

Оригинал этой записи в личном блоге.

Решил я тут попробовать одно приложение, написанное на Django. По рекомендации разработчиков поставил его с помощью easy_install, поскольку в родных дебиановских пакетах его нет. Всё поставилось, зависимости проверились, отсутствующие питоновские модули автоматически вытянулись и тоже поставились. И в их числе новая версия Django: 1.5.1. Стоявшая до этого дебиановская версия Django для этого приложения оказалась старовата.

А у меня там уже стояло одно довольно редко используемое, но вполне себе работающее приложение на Django, и я пошёл проверить, не сломалось ли оно. Конечно же, оно сломалось. 500 Internal server error, в клиента вываливается соответствующая страница с ошибкой, а подробностей нигде нету. Только вот эта запись в логе, и всё:
[pid: 23778|app: 0|req: 1/1] 46.7.*.* () {38 vars in 587 bytes} [Sun Mar 31 15:38:28 2013] GET / => generated 1275 bytes in 299 msecs (HTTP/1.1 500) 1 headers in 78 bytes (1 switches on core 0)

Включил в settings.py режим отладки: DEBUG=True… Опаньки, ошибка пропала, всё работает. Выключил DEBUG — опять error 500.

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

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Естественно, я на них наступил. Сами грабли скрыты где-то очень глубоко, я ещё точно не понял, где именно. Ошибок в логе нет, но попытки добавить или отредактировать некоторые объекты через администраторский интерфейс  вызывают ошибку 500 и сообщение “Sorry, an error occurred.” Причем показывается она в совершенно неправильном шаблоне — от режима просмотра сайта, а не от администраторского.

А самое смешное, что если включить Django’вский DEBUG, то… ошибка исчезает, добавление и редактирование работает нормально.

Препарирование пациента показало, что ошибка возникает при добавлении к объекту (любому) в качестве метаданных русских ключевых слов. Причём в базу они кладутся нормально, а вот при последующем их чтении происходит такая фигня где-то в глубинах рендеринга. А Django, типа, весь насквозь юникодный..

Оригинал этой записи. Комментировать можно тут или там.