Um efeito interessante do padrão WSGI é que ele pode tornar a vida dos sysadmins mais fácil. Por exemplo, publicar uma aplicação web em Python, com WSGI consiste apenas de:
- Descobrir como instanciar essa aplicação (específico de aplicação pra aplicação)
- Transformá-la em um cliente/middleware WSGI
- Publicá-la, usando a forma desejada.
Abaixo, segue um exemplo de uma publicação do mercurial, no apache, usando fastcgi.
#
# An example CGI script to export multiple hgweb repos, edit as necessary
import site
import sys
site.addpackage(‘/home/usuario/lib/python2.5/site-packages/’,‘easy-install.pth’,set(sys.path))
# enable importing on demand to reduce startup time
from mercurial import demandimport; demandimport.enable()
# If you’d like to serve pages with UTF-8 instead of your default
# locale charset, you can do so by uncommenting the following lines.
# Note that this will cause your .hgrc files to be interpreted in
# UTF-8 and all your repo files to be displayed using UTF-8.
#
#import os
#os.environ["HGENCODING"] = "UTF-8"
from mercurial.hgweb.hgwebdir_mod import hgwebdir
import mercurial.hgweb.wsgicgi as wsgicgi
from flup.server.fcgi import WSGIServer
application = hgwebdir(‘hgweb.config’)
WSGIServer(application, debug = True).run()
E o hgweb.config:
repositorio1 = /home/usuario/hg/repositorio1
repositorio2 = /home/usuario/hg/repositorio2
Compare com o deploy de Pylons via fastcgi, por exemplo. Depois de termos instanciado a aplicação (e isso varia de framework ou aplicativo), a forma de executar como fastcgi no apache é a mesma, usando o flup. E isso serviria para qualquer aplicação que disponibilizasse uma ‘saída’ WSGI. Prático não?
That’s cleared my thoughts. Thanks for cotnributing.
6EfdGL sixkibflhorp
afM6Gt pxejukujxqzt