пятница, 31 июля 2009 г.
Хочу другой линукс!
Повоевав с mod_wsgi, вроде приблизился к нормальной разработке, но не тут-то было: не захотел Django имена файлов с русскими буквами воспринимать. Оказалось, что Apache запускался с LANG=C, как это исправить даже в джанговских доках написано, но вот CentOS и тут отличился: настраивается не в /etc/apache2/envvars, а в /etc/sysconfig/httpd и даже называется не LANG, а HTTPD_LANG. Ну и после последних новостей есть уже огромный повод задуматься. Но это потом, ведь завтра отпуск начинается :)
вторник, 28 июля 2009 г.
R.I.P. mod_python
Проблемы в CentOS разрешились тривиальным удалением mod_python (с его помощью публиковался trac). Одновременно включить его и mod_wsgi не удалось, да и не нужно в принципе, trac ведь может и через wsgi работать.
В общем не надо 2 разными способами решать одну и ту же задачу одновременно - скорей всего только заморочки лишние нарисуются.
В общем не надо 2 разными способами решать одну и ту же задачу одновременно - скорей всего только заморочки лишние нарисуются.
пятница, 24 июля 2009 г.
Deployment не задался.
После войн сервером под CentOS пришёл к тому, что mod_wsgi поставить не удаётся, поэтому пока ограничусь mod_python. После отпуска надо будет задуматься о каком-то альтернативном хостинге.
суббота, 18 июля 2009 г.
О сколько нам пакетов чудных...
Пытаюсь сейчас разобрать деплоймент Django-приложений. Остановился на fabric, virtualenv и pip. Всё вроде бы интересно, но вот возникли некоторые неувязки - PIL не устанавливается через
можно, конечно использовать
но как-то "не спортивно", поэтому захотелось использовать site-packages куда будут установлены некоторые "дефолтные" пакеты (в т.ч. PIL). Только вот окружения, созданные через virtualenv, не хотели видеть глобальные пакеты. Пришлось посерьёзней разобраться с разбором импортов в python.
Причина оказалась в том, что товарищи из Ubuntu "пошаманили" с python 2.6 и site-packages зовутся dist-packages, буквально-таки:
поэтому ставить надо было не через sudo pip install/easy_install virtualenv, а с помощью sudo apt-get install python-virtualenv.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.
#pip install PIL
можно, конечно использовать
#pip install http://effbot.org/downloads/Imaging-1.1.6.tar.gz
но как-то "не спортивно", поэтому захотелось использовать site-packages куда будут установлены некоторые "дефолтные" пакеты (в т.ч. PIL). Только вот окружения, созданные через virtualenv, не хотели видеть глобальные пакеты. Пришлось посерьёзней разобраться с разбором импортов в python.
Причина оказалась в том, что товарищи из Ubuntu "пошаманили" с python 2.6 и site-packages зовутся dist-packages, буквально-таки:
if use_default_sitedirname:
return pylib.replace('/dist-packages', '/site-packages')
else:
return pylib
поэтому ставить надо было не через sudo pip install/easy_install virtualenv, а с помощью sudo apt-get install python-virtualenv.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.
среда, 15 июля 2009 г.
Дебажим джангу
Вроде начал толком писать приложение на Django и, естественно, понадобилось как-то отлаживать приложения. Довольно приятно был удивлён наличием удобных вещей по сравнению с PHP (или может я просто так плохо умею с ним обращаться?):
Оттуда же я узнал, что даже стандартная страница об ошибке Django информативнее, чем мне казалось (к примеру можно посмотреть участки кода и отправить стэктрейс на dpaste.com).
И ещё складывается такое впечатление, что на Django как-то больше думаешь о строении приложения с архитектурной точки зрения, т.е. как отдельные части взаимосвязаны и, возможно ли какое-нибудь переиспользование кода, а не с точки зрения "вот тут параметр А, надо отобразить табличку в Н строк". Хотя задачка не очень показательная, т.к. не из типовых для джанго, по-моему.
- bdp/ipdb позволяет ставить брейкпойнты в коде и делать пошаговую отладку, конечно, не Eclipse/Visual Studio, но вполне годно к использованию;
- django-debug-toolbar, о ней я уже писал, с тех пор там появилась ещё рубрика "сигналы";
- django-extensions в связке с werkzeug, про использование extensions для рисования диаграмм моделей я уже упоминал, но вот расширение страницы ошибки до того, что там становится доступна коммандная строка, меня сильно впечатлило.
Оттуда же я узнал, что даже стандартная страница об ошибке Django информативнее, чем мне казалось (к примеру можно посмотреть участки кода и отправить стэктрейс на dpaste.com).
И ещё складывается такое впечатление, что на Django как-то больше думаешь о строении приложения с архитектурной точки зрения, т.е. как отдельные части взаимосвязаны и, возможно ли какое-нибудь переиспользование кода, а не с точки зрения "вот тут параметр А, надо отобразить табличку в Н строк". Хотя задачка не очень показательная, т.к. не из типовых для джанго, по-моему.
среда, 1 июля 2009 г.
Чтож ещё почитать?
Дочитал Dive Into Python, как-то не очень меня впечатлила книга. Наверное, язык прост до того, что "разжёвывание" приёмов кажется черезмерным, да ещё и используемый там способ подачи материала в виде кода со сносками как-то мне совсем не по душе...
Следующей "питонистой" книгой, думаю должна стать Practical Django Projects, о которой я писал в предыдущем посте.
Или, может быть, есть что-нибудь другое стоящее внимания?
Следующей "питонистой" книгой, думаю должна стать Practical Django Projects, о которой я писал в предыдущем посте.
Или, может быть, есть что-нибудь другое стоящее внимания?
Подписаться на:
Сообщения (Atom)