PasteDeploy: ликбез для пользователей ∞
Продолжаем тему Paste. Сегодня разговор о PasteDeploy.
Вначале я просто думал перевести документацию по PasteDeploy, да что-то она какая-то замороченная, поэтому я попытаюсь изложить чуть попроще, а желающие могуть оценить оригинальный документ.
Зачем нужен PasteScript
Он нужен для одной единственной цели - дать способ конфигурировать WSGI-приложения, получая на выходе настроенное приложение в виде WSGI-приложения. Каламбур.
Еще раз. У вас есть некое WSGI-приложение. И необходима система конфигурирования. С ходу возникает идея просто хранить конфиг в отдельном модуле. Так, например, делает Django. Правда, он не использует явно модуль конфига, а подгружает его в свою настроечную систему, но не суть важно. Однако с этим подходом возникают проблемы, как только у вас возникнет желание компоновать WSGI-приложения в одном сайте с разными настройками. Например, Django в рамках одного проекта без специальных ухищрений не даст вам возможности использовать для блога одну БД, а для форума - другую. PasteDeploy худо-бедно (худо-бедно, потому что Ян Бикинг сделал упор на гибкость несколько в ущерб простоте, да и документация несколько хромает) решает эту проблему. Он дает возможность thread-safely настраивать WSGI-приложения.
Данная статья расчитана на пользователей PasteDeploy, т.е. у вас уже есть приложение. Что вам нужно знать, чтобы минимально настроить его:
Необходимый минимум
Конфиг Paste это INI-подобный файл. Все настройки разбиты по секциям (их еще по-другому называют разделами). У PasteDeploy есть схема их именования: [тип:название]
. Если имя секции не вписывается в схему, секция игнорируется (к примеру, это позволяет совершить финт ушами, когда один и тот же конфиг управляет и PasteDeploy, и logging). Имена разделов чуствительны к регистру.
Для минимума хватит два типа: app
и server
. Соответственно, первый описывает приложения, второй - сервера. Если у вас всего одно приложение и один сервер, то их название должно быть main
. Таким образом, в простейшем случае у вас один раздел [app:main]
, который может дополнятся [server:main]
. А, еще, глобальные настройки, общие для всех приложений и серверов находятся в разделе [DEFAULT]
.
Ок. Поехали дальше. Приложение или сервер должны инициировать какой-нибудь Py-код. Наиболее просто работать с eggs. Со специально подготовленными точками входа... но об этом должен думать разработчик приложения ;) Итак, в разделе сервера или приложения вы указываете какое яйцо использовать:
[app:main]
use = egg:PasteDeploySimplestExample
После названия яйца можно явно указать точку входа, разделяя их #
(не путайте с комментариями):
[server:main]
use = egg:PasteDeploySimplestExample#wsgiref
Таким образом, простейший конфиг выглядит примерно так:
[DEFAULT]
author = Yury Yurevich
description = The first config for PasteDeploy-enabled app
[app:main]
use = egg:PasteDeploySimplestExample
# однострочное значение
param_foo = It works!
# многострочное значение
param_bar = Multiline is
supported. Just
indent it.
# boolean значение, можно использовать 1/0, True/False, true/false
param_baz = 1
[server:main]
use = egg:PasteDeploySimplestExample#wsgiref
# для большинства серверов актуально как миниму два параметра:
# хост
host = 127.0.0.1
# и порт
port = 8080
Сохраняем его в example.ini, и запускаем при помощи PasteScript: paster serve example.ini
.
Зная это, вы сможете по-минимуму настраивать приложения.
Играйтесь с PasteDeploySimplestExample, код - как обычно, на code.google.com.
Продолжение следует...