Вспомнил, что начинал читать Pro Django, и решил продолжить это дело. И почти сразу нашёл пояснение к предыдущей проблеме с переменными в блоках DTL: контекст, передаваемый в шаблоны организован в виде стэка.
Оказалось, что и в официальных джанговских доках это тоже описано.
P.S. В комментах и в своём блоге alerion дал решение в прошлый раз (но до его блога я не добрался, а приведённый вариант был не до конца понятен).
суббота, 17 апреля 2010 г.
вторник, 13 апреля 2010 г.
Продолжая тему нескольких портов
Разбираем дальше вчерашнюю тему нескольких сайтов на одном хосте.
Скорее всего вам не помешает, чтобы можно было заходить одновременно в несколько админок на разных сайтах (т.е. разных портах). По умолчанию это не сработает, т.к. куки сессии будет совпадать для обеих сайтов. По-моему логично разрешить проблему при помощи разных SESSION_COOKIE_NAME в файлах настроек.
Скорее всего вам не помешает, чтобы можно было заходить одновременно в несколько админок на разных сайтах (т.е. разных портах). По умолчанию это не сработает, т.к. куки сессии будет совпадать для обеих сайтов. По-моему логично разрешить проблему при помощи разных SESSION_COOKIE_NAME в файлах настроек.
О портах в nginx
Потребовалось развернуть 2 разных инстанса сервера на джанго на одном и том же хосте, но на разных портах.
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".
воскресенье, 11 апреля 2010 г.
Pip, о сколько в этом слове...
Что-то вот совсем понять не могу в чём проблема и как её диагностировать:
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.
четверг, 8 апреля 2010 г.
суббота, 3 апреля 2010 г.
А мужики-то не знают!
Обнаружил , что у pip есть опция кэшировать загружаемые пакеты. Для этого надо присвоить переменной окружения $PIP_DOWNLOAD_CACHE папку, где будет располагаться этот кэш.
Забавно, но на оф. сайте pip эта опция фигуриует только в новостях.
На самом деле захотелось сделать развёртывание совсем с 0, с созданием virtualenv и не заморачиваясь на исправление зависимостей, но каждый раз скачивать десяток мегабайт по-моему всёж некоторое расточительство, особенно когда состав пакетов менятся довольно редко. Пусть даже и в наше время мегабитных подключений.
Забавно, но на оф. сайте pip эта опция фигуриует только в новостях.
На самом деле захотелось сделать развёртывание совсем с 0, с созданием virtualenv и не заморачиваясь на исправление зависимостей, но каждый раз скачивать десяток мегабайт по-моему всёж некоторое расточительство, особенно когда состав пакетов менятся довольно редко. Пусть даже и в наше время мегабитных подключений.
Подписаться на:
Сообщения (Atom)
