Atualizações no Mundo Python
Os últimos dias foram cheios de atualizações para os pythonistas 
. Devido a um problema no empacotamento, 3 dias após o lançamento do Django 1.0.1, foi lançado o 1.0.2. Para quem usa o Google AppEngine, problema semelhante aconteceu: 3 dias após o lançamento do 1.1.6, saiu o 1.1.7 para corrigir bugs de última hora.
O Pylons se aproxima da versão 0.97 final, no última dia 24 saiu o Release Candidate 4, que eles esperam ser o último. A documentação atualizada você pode ver em http://docs.pylonshq.com/ ou baixar em PDF.
O Michael Bayer (SQLAlchemy, Mako), após usar o Beaker (middleware WSGI de Cache e Sessão) em produção, corrigiu muitos bugs nos caches em arquivo e memcached. Eu enviei um patch minúsculo que fez com que ele voltasse a funcionar com o Google AppEngine e tudo isso já está disponível na versão 1.1.2. Outro projeto que agora funciona melhor com o Google AppEngine é o FormEncode. A versão 1.1 tinha introduzido um pequeno problema com o Google AppEngine, que foi corrigido no FormEncode 1.2
Ao colaborar com a tradução da documentação do Django para português, descobri um problema com o CSS, que depois acabou se revelando um problema com a dupla docutils + Sphinx. Enquanto o bug era testado, saiu uma nova versão, o Sphinx 0.5. O Sphinx se tornou muito popular na geração de documentação para projetos Python (a documentação do Pylons que eu citei agora a pouco é gerada com Sphinx).
É isso, hora de atualizar os virtualenvs da vida
por Walter Cruz em Python, Django, Pylons
Pylons e TurboGears
Alguns dias atrás, alguém fez a seguinte busca no google: "Pylons é melhor do que turbogears?" e acabou caindo aqui no blog. Dizer qual entre dois frameworks é o melhor é uma tarefa difícil, e pode causar convulsões em algum fanboy (talvez não seja o caso, já que ambos estão ficando em segundo plano por causa do Django, ao menos aqui no Brasil). Porém isso não nos impede de dar uma pequena olhada nos pontos em que esses frameworks se diferenciam e onde está o poder de cada um deles.
TurboGears
O TurboGears é um framework construído por diversas partes (ao contrário do Django, onde toda a stack parte de um mesmo lugar). Atualmente, usa o CherryPy, SQLObject para mapeamento objeto relacional, Kid para templates MochiKit para JavaScript e AJAX. O Framework foi criado por Kevin Dangoor, e teve seu desenvolvimento iniciado no começo de 2005.
Pylons
O desenvolvimento do Pylons começou no início de 2006, e tinha como um dos objetivos, na época, ser uma resposta ao Ruby on Rails, tanto que possui alguns componentes portados do próprio Rails, como o sistema de roteamento de URLS e controladores (Routes) e o WebHelpers. Outra decisão que direciona o projeto até hoje é o fato dele dar extremo valor ao padrão WSGI. Atualmente, o projeto está chegando a versão 0.97. O WebHelpers está sendo praticamente reescrito - a geração de código javascript, e as funções link_to_remote, por exemplo, estão caindo em desuso. Segundo os autores, o framework não deve ser acoplado a nenhuma biblioteca JavaScript, até porque elas estão em constante evolução e a biblioteca da vez sempre muda, o que faria com que sempre alguém ficasse descontente por não ter sua biblioteca preferida suportada. Segundo o Charleno Pires, o Pylons é de certa forma semelhante ao Merb (Ruby), ao prover um framework pequeno e bastante personalizavel.
TurboGears 2
Um julho de 2007, uma surpresa aconteceu: após um sprint, o pessoal do TurboGears decidiu implementar o TurboGears 2 usando o Pylons como fundamento (trocando então o CherryPy). Na época algumas pessoas acharam esquisito implementar um framework sobre o outro (porém, o mesmo acontece com zope, ao pesarmos em CMF>Plone>Archetypes), e houve até uma especulação sobre um possível merge dos dois projetos. Porém, os dois projetos tem propósitos e visões diferentes. Enquanto o Pylons é mais um meta-framework, uma base crua sobre a qual idéias podem ser desenvolvidas, o TurboGears já pressupõe que você irá usar um banco de dados relacional (suposição que o Pylons não faz), possui algumas ferramentas para geração de formulários, ou seja, provê de certa forma uma estrada mais pavimentada para o usuário do framework. Você pode encontrar mais informações sobre o porquê desse merge não ter acontecido na documentação do TurboGears.
E o resultado é...
Entender a história dos frameworks, junto com a experiência de uso deles, é a melhor forma de fazer uma boa escolha. Espero ter contribuído com essa escolha ao detalhar um pouco da história desses dois frameworks!
Links
- Rum - Um 'gerador de CRUD para SQLAlchemy, feito pelo Alberto Valverde.
- Uma introdução ao WSGI - Ian Bicking
- WSGI - a resposta para a questão definitiva sobre Python, a web e tudo mais? - Humberto Diógenes
- Pylons Book Livro sobre o Pylons (em fase de escrita ainda)
- Documentação do TurboGears 2
- Documentação da versão 0.97 do Pylons
por Walter Cruz em Python, Ruby, Rails, Pylons
Mercurial na web com apache e fastcgi
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?
por Walter Cruz em Python
Deploy simplificado de Pylons via FastCGI
Em um pequeno projeto que fiz com Pylons, o arquivo a ser executado pelo FastCGI era como o seguinte:
#!/usr/bin/env python2.5
import os, sys
lib_path = "/home/usuario/lib/python2.5/site-packages/"
sys.path.append(lib_path)
sys.path.append('/home/usuario/projects_pylons/project/')
from pkg_resources import require
require("Pylons")
require('python-openid')
require("AuthKit")
require("Elixir")
require("flup")
require('docutils')
require("pygments")
from paste.deploy import loadapp
wsgi_app = loadapp('config:/home/usuario/projects_pylons/project/server.ini')
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app, debug = True).run()
Mas qual a razão de todos esses requires? A questão é que todos essas bibliotecas são eggs instaladas no diretório $HOME do usuario. Numa sessão normal do interpretador python, ao ser iniciado, ele detecta todos os eggs disponíveis em PYTHONPATH e os adiciona ao sys.path. Assim, ao fazer o import de algo que está em um egg, ele consegue encontrar a versão correta. Você pode até mesmo fazer um pequeno teste: execute o interpretador python, importe o módulo sys e imprima o sys.path. Você vai ver uma lista de todos os paths disponíveis, inclusive os seus eggs lá.
Mas executando num ambiente fastcgi, a variável PYTHONPATH não estava definida, e essa pequena magia de adicionar os módulos em eggs no sys.path acontece na hora da inicialização do interpretador. Por isso o require: depois que eu adicionei o /home/usuario/lib/python2.5/site-packages/ ao sys.path, cada chamada ao pkg_resources.require irá procurar o egg correspondente, inclusive nesse path. Mas observe que são sete linhas apenas com require (e isso porque o require do Elixir já trouxe o SQLAlchemy de brinde, se não teria sido mais uma. Provavelmente uma boa saída teria sido fazer uma instalação completa do python no meu $HOME, ou usar algo como o virtualenv, mas não era da forma como eu queria.
Minha primeira idéia foi usar o módulo glob, procurar por todos os eggs e adicionar no meu sys.path Isso funcionaria, exceto por um inconveniente: ao instalar uma nova versão do pacote, o easy_install não apaga o egg anterior. E se houvessem mais de uma versão do pacote nos eggs, qual ele usuaria, a primeira versão encontrada na lista? Era hammeragem o bastante. Após alguma pesquisa, consegui enxugar o código para:
#!/usr/bin/env python2.5
import sys
sys.path.append('home/usuario/projects_pylons/project')
import site
site.addpackage('/home/usuario/lib/python2.5/site-packages/','easy-install.pth',set(sys.path))
from paste.deploy import loadapp
wsgi_app = loadapp('config:/home/usuario/projects_pylons/project/server.ini')
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app, debug = True).run()
O segredo todo estava no módulo site. Com isso, todos os eggs disponíveis em home/usuario/projects_pylons/project estão disponíveis para importação!
por Walter Cruz em Python, Pylons
