Все публикации с тегом “Paste”

PasteDeploy: введение для разработчиков

Вторая статья про PasteDeploy, теперь уже для разработчика. Крайне рекомендую предварительно ознакомиться с первой статьей.

Итак, вы решили, что в вашем приложение неплохо бы использовать PasteDeploy. Это сделать очень просто, что я вам и продемонстрирую.

продолжить чтение

PasteDeploy: ликбез для пользователей

Продолжаем тему Paste. Сегодня разговор о PasteDeploy.

Вначале я просто думал перевести документацию по PasteDeploy, да что-то она какая-то замороченная, поэтому я попытаюсь изложить чуть попроще, а желающие могуть оценить оригинальный документ.

Зачем нужен PasteScript

Он нужен для одной единственной цели — дать способ конфигурировать WSGI-приложения, получая на выходе настроенное приложение в виде WSGI-приложения. Каламбур.

Еще раз. У вас есть некое WSGI-приложение. И необходима система конфигурирования. С ходу возникает идея просто хранить конфиг в отдельном модуле. Так, например, делает Django. Правда, он не использует явно модуль конфига, а подгружает его в свою настроечную систему, но не суть важно. Однако с этим подходом возникают проблемы, как только у вас возникнет желание компоновать WSGI-приложения в одном сайте с разными настройками. Например, Django в рамках одного проекта без специальных ухищрений не даст вам возможности использовать для блога одну БД, а для форума — другую. PasteDeploy худо-бедно (худо-бедно, потому что Ян Бикинг сделал упор на гибкость несколько в ущерб простоте, да и документация несколько хромает) решает эту проблему. Он дает возможность thread-safely настраивать WSGI-приложения.

продолжить чтение

Django-приложения без проектов

Малькольм Трединник написал статью про то, как в Django можно обойтись без проектов.

Во многом, положения этой статьи пересекаются с моими собственными предпочтениями: последнее время я работаю исключительно с приложениями, не с проектами. Во-первых, распространяются (в виде tarball или egg) приложения, а не проекты. Во-вторых, как я уже говорил, проекты это лишняя сущность, по факту они никому не нужны.

Особых секретов в моем подходе нет — единственно, что я создаю приложение не средствами django-admin.py, а средствами PasteScript: в этом случае уже всё готово и для “приложения без проекта”, и для пакетизации (setup.py рядом лежит).

Давайте прикинем, какие действия необходимо совершить, желая создать сайт на Django через django-admin.py:

  • создать проект django-admin.py startproject projectname
  • внутри проекта создать приложение python manage.py startapp appname
  • скопировать шаблон urls.py из проекта в приложение
  • в settings.py проекта включить приложение в INSTALLED_APPS
  • в urls.py проекта подключить urlconf из приложения

Вдобавок к этому, сложно придумать адекватные имена и проекту, и приложению, обычно либо проект получается mysite или типа того; либо воображения хватает только на проект, и приложение получается foo.foo.

C шаблоном приложения PasteScript всё сводится к:

  • создать приложение paster create -t django AppName

По-хорошему, неплохо бы еще и развертывание делать через PasteDeploy, даром что Django поддерживает WSGI. Для ситуации “один сайт — одно приложение” все делается достаточно легко, и я делал такое в тестовых целях. А вот для расклада “один сайт — несколько приложений”, да еще с разными настройками (например, БД) возникают сложности, связанные с концептуальными решениями Django. Так что полноценную поддержку Django в Paste сделать достаточно проблематично, а частичное решение не понятно кому нужно…

P.S.Уже после того, как написал пост заметил, что и Джеймс Беннетт высказался на тему “жизнь без проектов”.

WSGI, Paste

Продолжим работать с WSGI. Сегодня поговорим о Paste.

продолжить чтение

Две вишенки для гиков

Я не использую CherryPy, и в ближайшем будущем не планирую. Но эти два проекта привлекли своей нестандартностью.

RhubarbTart — WSGIsh CherryPy

RhubarbTart — это “стиль CherryPy на WSGI-движке”. То есть внешний API от CherryPy, но сделано на Paste.

Слово автору — Джулиану Краузе:

Q. Зачем еще один фреймворк?
A. RhubarbTart не новый фреймворк, это комбинация двух существующих фреймворков: пользовательский API и структура кода CherryPy, и инфраструктура Paste. Пересмотр старых вещей ради создания новых — необходимое условие эволюции.

Q. Получится ли просто поместить свой CherryPy-код в RhubarbTart?
A. Скорее всего нет. Хотя RhubarbTart по возможности использует имена и методы CherryPy, он не реализует все возможности CherryPy. Больше всего нареканий к тому, что не реализованы фильтры. Мы надеемся, что большинство фильтров можно заменить декораторами или WSGI middleware.

TurboGears new traversal — Cherrie Nevow

TGNewTraversal — управление URLами в стиле Nevow в TurboGears/CherryPy-приложениях.

Вот что говорит Даг Винтер о своём проекте:

Если вы создаете крупное, сложное приложение, вам нужен полный контроль над обходом (имеется ввиду обход методов контроллера при определении, какой метод будет “работать” для данного URLа, англ. traversal — прим. pythy), и CherryPy не дает такой возможности. Для того, чтобы механизм обхода нормально работал, необходимо зафиксировать компоненты URLа. Если же вы хотите, чтобы компоненты URLа могли меняться, то придется писать много кода, большая часть которого — “борьба” с CherryPy.

По мне это большой недостаток приложения, которое в остальном весьма приятно. […]

Основная альтернатива — использовать Routes, портированный с Rails. Я упоминаю его, но мне очень не нравится такой подход — я думаю, что регулярные выражения — не лучший способ решения архитектурных проблем.

Так что встречайте TGNewTraversal. Я взял код механизма обхода из Nevow, на мой взгляд, это лучший способ обхода. Я немного “допилил” его для большей дружелюбности к CherryPy. Совсем немного кода нужно для того, чтобы приобщиться к грамотной концепции обхода из Nevow.