Мне всегда казалось, что для небольших проектов использование buildout - это как с пушки по воробьям: долго, сложно и неудобно. Хотелось чего-то более простого и понятного. И таким оказалась связка virtualenv + pip.

Про virtualenv я уже писал тут. pip - это замена easy_install, менеджер пакетов для python, который позволяет быстро и удобно устанавливать, обновлять и удалять пакеты. Более подробно можно почитать на официальном сайте. Сейчас же меня интересует возможность быстрого развертывания необходимого окружения для запуска проекта. В двух словах, задача выглядит так:

Нужно запустить проект, который для работы требует следующие пакеты:

• Django;
• SQL Alchemy;
• pep8 & pylint для проверки кода.

Стандартный алгоритм решения - создать новое окружение с помощью virtualenv и установить нужные пакеты. Но ведь не делать же это каждый раз каждому разработчику руками? А на build-сервере? Пришедшая мне первая мысль (написание нужного bash-скрипта) к счастью, оказалась не совсем правильной. Т.е. для полной автоматизации небольшой bash-скрипт будет не лишним, но вот устанавливать пакеты проще и правильнее через pip. Итак, как же нам установить все необходимые пакеты?

Шаг 1. Создаем virtual environment

$ virtualenv ./pip-test/ --no-site-packages

Ключ --no-site-packages указывает на то, что в нашем окружении не будет доступа к пакетам, установленных в операционной системе. Такая себе чистая, ничем не испачканная песочница.

Шаг 2. Устанавливаем нужные пакеты

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

$ pip install Django
$ pip install SQLAlchemy
$ pip install pep8
$ pip install pylint

Шаг 3. Автоматизируем установку пакетов

После установки нужных пакетов можно выполнить команду pip freeze -l, которая выведет на экран список установленных пакетов с их версиями. В моем случае, это выглядит так:

$ pip freeze -l
Django==1.3.1
SQLAlchemy==0.7.4
logilab-astng==0.23.1
logilab-common==0.57.1
pep8==0.6.1
pylint==0.25.1

Ключ -l выводит пакеты установленный только внутри virtualenv, что при создании окружения с ключем --no-site-packages теряет всякий смысл.

Далее этот список нужно сохранить:

$ pip freeze -l > pip-requirements

Тепреь в файле pip-requirements лежит список всех необходимых для запуска пакетов. Этот нужно положить в вашу source control и при необходимости обновлять.

Чтобы установить все необходимые пакеты, необходимо выполнить команду:

$ pip install -r pip-requirements

Несколько рускоязычных статей про buildout можно найту тут: http://www.vurt.ru/tag/buildout

Все сказанное ниже является личным мнением автора и не является объективной точкой зрения и/или истиной последней инстанции.

Я всегда считал и продолжаю это делать, что Django - не очень-то и модульный фреймворк. Он расширяемый, но не модульный, IMHO. В моем понимании модульный фреймворк, это фреймворк, который состоит из ядра (core), и каких-то модулей, которые можно к нему подключать при желании/необходимости. Но и без них будет доступна минимальная функциональность. В случае же Django - выкинуть из него некоторые модули (e.g. models, template engine) достаточно сложно. Что-бы сделать что-то подобное, необходимо самостоятельно удалять ненужные куски кода, что тянет за собой проверку работоспособности оставшихся частей и прочие неприятности в виде сложной поддержки полученного кода и обновление фреймворка.

Django - легко расширяемый фреймворк. Это видно по django.contrib и многочисленных сторонних дополнений и приложений. Но при добавлении нового, все-равно есть возможность пользоваться старыми стандартными модулями Django.

Т.к. этот вопрос интересует меня давно, я его задавал одному из Django Core Developers, Andrew Goodwin’уб на прошедшем в октябре UA Pycon. Далее в вольном пересказе пишу его слова так, как я их понял:

“Мы знаем об этой проблеме и у нас есть в планах заняться этой задачей. Но есть еще масса более важных задач, которые нужно делать. Поэтому я не могу сказать, когда мы начнем это реализовывать. Также по идеологии Django нужно совместимость версий: код, написанный для текущей версии, должен без изменений работать на следующей.

И есть еще одна проблема: community хочет не только модульность самого Django, но и возможность использование его компонентов, например models, вне Django. В данной это невозможно, но мы хотим когда-нибудь это сделать”

Несколько ссылок по теме из википедии:

• http://en.wikipedia.org/wiki/Extensibility
• http://en.wikipedia.org/wiki/Modularity_(programming)

Никогда не знаешь, где упадет OpenStack(c) 
Я, в процессе очередного дебагга.

Те, кто читает мой твиттер (@e0ne), должны знать, что в последнее время я работаю с OpenStack’ом, а именно занимаюсь(конечно, не один я) попытками его запуска на Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux, etc. Т.к. все это построено на базе полной и непросветной enterpise в виде RHEL, то сборка нового дистрибутива, как правило, у меня начинается со сборки именно под эту ОС. 

Вот я и хочу поделиться своими впечатлениями от сборки последней версии OpenStack’а под RHEL. Началось все с попытки запустить чуть менее чем полностью поломанную версию essex-1. Потом все продолжилось с версией essex-2. Основные моменты, которые мешали мне радоваться жизни - переделки в glance, связанные и security, которые на время поломали работоспособность EC2 API. 

Проект Glance - это услуги по отбору, регистрации и поиску виртуальных «machine images» (VMI). В рамках Glance используется RESTful API, что позволяет делать запрос метаданных VMI и выполнять поиск фактического образа (VMI). (http://openstack.ru/openstack_glance.html)

И тут я решил попробовать запустить все из последней версии исходников, с master’а...

После небольших усилий инстансы (виртуалки) начали запускаться, но были проблемы с сетью. Команда “killall dnsmasq”, подсказанная моим коллегой, решила часть проблем, а именно - выдачу IP адреса виртуальной машине. Далее в логах при загрузке неворуженым глазом были замечены такие проблемы:

Что означало, что запущенный инстанс не может получить данный от Metadata Server’а. Т.к. Metadata Server нормально работал в Diablo, то сразу вспомнились 2 вещи:

• файл nova-api-metadata, который помешал успешно собрать RPM с essex-2 используя spec-файл из Diablo
• и то, что в essex-2 Metadata Server теперь существует отдельно от Nova API (http://fnords.wordpress.com/2011/12/20/ending-the-year-well-openstack-essex-2-milestone/, https://blueprints.launchpad.net/nova/+spec/separate-nova-metadata).

Далее по аналогии с Nova API был создан файл /etc/init.d/openstack-nova-api-metadata, который предназначался для запуске сервиса Metadata Server’а. Metadata Server, на первый взгляд, успешно запустился, то я попытался запустить снова инстанс, что мне привело к предыдущей ошибке. Логи Metadata Server’а немного испугали:

Мозг сразу начал представлять кошмары, связанные с выводом strace, linux kernel debugger’ом и так далее. Вовремя опомнившись, я полез в Google. Поиск по “exit code 134” ничего полезного не дал. А вот поиск по “iptables-restore buffer overflow” дал нужный результат в виде двух багов iptables: http://bugzilla.netfilter.org/show_bug.cgi?id=641 иhttps://bugzilla.redhat.com/show_bug.cgi?id=545600. Довольно-таки стандартное, на сколько мне известно, переполнение буфера, вызванное функцией strcpy, которую, к слову, не очень-то и рекомендуют использовать. Подробности в этом комментарии: https://bugzilla.redhat.com/show_bug.cgi?id=545600#c6

Т.к. обновление iptables в RHEL 6.1 - не самая приоритетная для меня задача, то я решил зайти с другой стороны - посмотреть что же делает OpenStack для получения такого результата.

https://github.com/openstack/nova/blob/master/bin/nova-api-metadata

Metadata Server запускается таким же способом, как и другие REST-сервисы Nova, поэтому проблему нужно было искать где-то дальше. Об этом же говорили и логи, и ошибка, связанная с iptables.

https://github.com/openstack/nova/blob/master/nova/network/linux_net.py

Метод metadata_accept() отрабатывает без ошибок и падает все в iptables_manager.apply().

Т.к. данный метод используется далеко не в одном месте

то ошибка где-то в передаваемых параметрах. В качестве параметров к iptables-restore у меня передавалось такое:

 ip-restore-full.jpg

Зная о баге в iptables и то, что падало все только при запуске Metadata Server’а, то получилось быстро найти нужную команду, которая все ломала:

iptables-restore <<EOF
*nat
:nova-api-metadata-POSTROUTING - [0:0]
-A POSTROUTING -j nova-api-metadata-POSTROUTING
COMMIT
EOF

len(‘nova-api-metadata-POSTROUTING’)==29, что вместе с символом конца строки в языке С давало нам 30 символов и при копировании их в массив из 29 символов давало нам переполнение буффера (см. ссылки на баги выше). Хорошо, проблема найдена, теперь нужно ее устранить. Для этого находим код, где у нас генерируется имя chain’а:

chain1.jpg, chain2.jpg

где:

binary_name = os.path.basename(inspect.stack()[-1][1])

Таким образом проблема была в имени исполняемого файла. Переименовав “/usr/bin/nova-api-metadata” в “/usr/bin/nova-metadata ” все заработало. Вопрос лишь в том, насколько долго оно будет работать с таким “фиксом”? 

Более правильное решение нужно делать исправляя код OpenStack’а и/или обновляя iptables. Также интересно как это себя ведет на других RHEL-based дистрибутивах(версия iptables) и ubuntu, но это уже проверю завтра, а пока поставил качаться нужные образы дистрибутивов...

[Update]

Баг с iptables проверен после установки чистой ОС после установки всех апдейтов с помощью команды "yum update" на следующих ОС:

• RHEL 6.1 x86_64 - iptables v1.4.7, buffer overflow detected
• RHEL 6.2 x86_64 - iptables v1.4.7, buffer overflow detected
• CentOS 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
• CentOS 6.2 x86_64 - iptables v1.4.7 buffer overflow detected
• Scientific Linux 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
• Fedora 15 x86_64 - testing in process
• Fedora 16 x86_64 - testing in process

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

• подключения специальной версии CSS;
• подключения нужных JavaScript’ов;
• создание мобильных шаблонов (templates) с версткой (html).

Сразу оговорюсь, что вопрос мобильной верстки сейчас затрагивать не буду.

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

{% if request.mobile %}
    Mobile
{% else %}
    Not mobile
{% endif %}

Или же наша view поменяет вид на такой:

def index(request):
    if not request.mobile:
        return render_to_response('index.html’)
    else:
        return render_to_response('mobile_index.html’)

Теперь дело за малым - сделать так, чтоб в объекте нашего запроса (request’а) появилось свойство mobile. Один из самых простых и достаточно эффективных способов - посмотреть какой USER_AGENT у браузера, который делает запрос. Для этих целей уже есть небольшой, но удобный компонент minidecector, который анализирует USER_AGENT из запроса и выставляет нужное значение свойства request.mobile.

minidetector можно подключать двумя способами:

• добавление декоратора detect_mobile к нужной view;
• добавление уже готового Middleware; в этом случае будут обрабатываться все запросы к нашему приложению.

Небольшой пример использования minidetector лежит на GitHub’e: https://github.com/e0ne/BlogSamples/tree/master/MobileTest

Другие ссылки по теме:

• http://stackoverflow.com/questions/164427/change-django-templates-based-on-user-agent
• http://code.google.com/p/minidetector/
• http://stackoverflow.com/questions/2321172/detect-mobile-browser-not-just-iphone-in-python-view

Рассмотрим задачу сравнения двух инстансов простого класса A в Python. Сам класс A выглядит так:

class A(object):
    def __init__(self, int_param):
        self.int_value = int_param

В данном случае, если мы выполним такой код:

a1 = A(1)
a2 = A(1)

то инстансы этого классы не будут равны между собой:

a1 == a2 - False
a1 is a2 - False

Чтобы понять как это все работает и почему получается такой результат рассмотрим функцию id(object). Функция id() возвращает идентификатор объекта, который будет уникальным и неизменным на протяжении времени жизни объекта. В CPython эта функция возвращает адрес объекта в памяти. В моем случае это:

id(a1)=4299743824
id(a2)=4299743888

Теперь, если мы посмотрим на документацию оператора is, то увидем, что он возвращает True, только в случае, если, в нашем случае a1 и a2, - один и тот же объект. В таком случае, если сделать a3=a1, то получим:

a3 == a1 - True
a3 is a1 - True

Оператор “==” сравнивает объекты с помощью метода __cmp__, который может возвращать одно из 3-х значений:

• -1  - в случае, когда один объект “меньше” (<) другого;
• 1  - в случае, когда один объект “больше” (>) другого;
• 0  - объекты равны (==).

Самая простая реализация этого метода выглядит так:

class B(object):
    def __init__(self, int_param):
        self.int_value = int_param

    def __cmp__(self, other):
        if self.int_value < other:
            return -1
        elif self.int_value > other:
            return 1
        else:
            return 0

После этого получаем такой вывод:

b1 = B()
b2 = B()
b1 == b2 - True
b1 is b2 - False

Примеры кода, традиционно, на GitHub’e: https://github.com/e0ne/BlogSamples/tree/master/PythonEquals

В Киеве ежегодно проходит PyCon, переодически собираются встречи Kyiv.Py - жизнь python community по немного идет своим ходом. А вот в Харькове, к сожалению, ничего подобного не было (не считая DevTime прошедшей весной). Вот мне и хахотелось собрать харькоское python community для общения, обменом знаниями и опытом.

Подробности на http://kharkivpy.org.ua/

При установке пакетов psycopg2 и lxml easy_install радостно падал с криками:

unable to execute gcc-4.2: No such file or directory
error: command 'gcc-4.2' failed with exit status 1

Вполне логично, т.к. gcc у меня не стоял :(. Странно только что в Snow Leopard все работало. Немного полазив по инету нашел, что gcc ставится вместе с XCode, который ставится бесплатно из Mac App Store. Но и это не сразу помогло. Ниже привожу список шагов, которые понадобились для установки gcc и psycopg2 после этого.

1. Из Mac App Store устанавливаем XCode.
2. Добавляем в переменную PATH путь к gcc: export PATH=$PATH:/Developer/usr/bin
3. Чтобы работало после перезагрузки и для всех пользователей прописываем этот путь и в /etc/paths

Сейчас только ленивый не писал об облаках. То, что раньше было просто веб-сервисом - сайчас SaaS. Вот раньше я пользовался gmail просто как почтой, теперь мне навязывают что это SaaS и поэтому это еще лучше. Как пользователю - мне все-равно как оно устроено.  Но вернемся ближе к теме поста и посмотрим какие облака вообще бывают.

Наиболее распространенные типы облаков (clouds) это (точные определения можно найти на Википедии, я говорю так, как выглядит это для меня):

• SaaS (Software as a Service) - софт, как правило, веб-приложения, который работает где-то там на на сервере и не требует установки и/или мощного клиента. Такое себе арендованное ПО.
• PaaS (Platform as a Service) - платформа для разработки ПО (Google App Engine, Azure). Позволяет с минимальными усилиями писать масштабируемые приложения. Тут провайдер PaaS берет на себя все или почти заботы по масштабированию приложения, обеспечению беспрерывной работы, администрированию серверов и т.д.
• IaaS (Infrastructure as a Service) - грубо говоря, вам в аренду даются n-е количество серверов(облако), где при необходимости можно быстренько добавить и/или уменьшить количество серверов, памяти на них, объем винчестеров и т.д. Как пример IaaS - Amazon EC2.

Разработка любого облака - достаточно сложное и интересное занятие. Создать с нуля можно, но много уже есть готового. Opensource проектов для создания своего приватного клауда становится все больше. Openstack - один из таких проектов. Это IaaS платформа, написанная на Python. Если немного погуглить, то можно найти нечто похожее на Java и Ruby.

Описывать архитектуру и как работает Openstack я сейчас не буду. Я расскажу лишь о том, что нужно знать для комфортной работы с Openstack’ом. Мне, как веб-разработчику было достаточно быстро войти в процесс, т.к. проект требует спецефических знаний. Один лишь список модулей питона, которые необходимы для запуска одного из компонентов Openstack’а nova содержит 35 пунктов.

• Python - ведь на нем все написано. Как правило, код достаточно простой и понятный, много комментариев. При написании кода соблюдается PEP8.
• Знание linux-подобных ОС. Прежде всего, Openstack разрабатывался для работы под Ubuntu, но есть сборки и для других ОС. Под другими ОС имеется в виду Red Hat, CentOS, Fedora и т.д. И врядли он когда-нибудь будет работать под Windows - уж слишком много OS-specific мест наподобии работы с образами виртуальных машин, работа с сетью и т.д. Так же количество гипервизоров по linux значительно больше. Комфортная работа с консолью и понимание того как устроена ОС - навыки, без которых сложно будет работать.
• Так как одной из основных задач Openstack’a является запуск виртуальных машин(серверов), то знание того как работает виртуализация будут большим плюсом.
• Работа с сетью, понимание как что работает (VLAN, bridge-интерфейсы, маршрутизация и т.д.), уметь пользоваться iptables.
• Git - проект хостится на GitHub’е.

Openstack в сети: http://openstack.org
GitHub: https://github.com/openstack

Очередное мероприятие под названием PyCon будет в Киеве уже менее чем через месяц. Мой очень короткий отчет о том, что было в прошлом году находится тут: http://blog.e0ne.info/post/UaPycon-how-it-was.aspx. В этом году должно быть еще больше и лучше.

Доклады

В этом году мы планируется провести двухдневную конференцию в два потока — включая доклады, мастер-классы, панельные дискуссии и lighting talks. Кроме того, будет проведена «recruiting session» — у желающих будет возможность больше узнать о украинских компаниях, которые разрабатывают на питоне, об их проектах и побеседовать с их представителями.

Среди докладчиков ожидаются:

• Игорь Почечуев, Василий Дижак, Тарас Мурашко, Игорь Давыденко, Андрей Светлов, Павел Коломиец, Александр Соловьев, Роман Ворушин (Киев, Украина)
• Александр Бойко (Харьков, Украина)
• Александр Лябах (Днепропетровск, Украина)
• Михаил Кашкин (Одесса, Украина)
• Александр Литовченко (Донецк, Украина
• Юрия Юревич (Омск, Россия)
• Армин Ронахер (Armin Ronacher, Австрия)
• Ендрю Годвин (Andrew Godwin, Великобритания
• Мартин Шустрик (Martin Sustrik, Словакия)
• Анжей Млечко (Andrzej Mleczko, Италия)
• Маттео Босколо (Matteo Boscolo, Италия)
• Ожидаются подтверждения участия от Тарека Заде (Tarek Ziade) и Luke Kenneth Casson Leighton.