Desenvolvimento web hoje em dia é quase sinônimo de algum tipo de framework. Mesmo PHP, que é por tradição uma linguagem com tendência à certa desorganização, tem se adaptado e bons frameworks tem surgido nessa linguagem.
Minha linguagem preferida, como todos sabe, é Python. E nesse universo, frameworks é o que não faltam. O momentum agora é do Django, mas Zope/Plone tem seu espaço garantido. TurboGears já alcançou alguma reputação. Até o minimalista webpy tem o seu lugar. Nessa miríade de opções, a minha escolha recaiu sobre o Pylons. Assim como o TurboGears, o Pylons não é um framework full-stack, mas se define como um código cola entre outros componentes. Provavelmente, o Pylons seja melhor definido como um meta-framework do que como um framework. Talvez fique num lugar intermediário entre os dois, e já explico o por quê.
Uma das coisas que eu penso que define um framework é o fato de que ele toma decisões por você. Como é dito no jargão Rails, um framework é um software com opnião. O Rails já pressupõe que você usará o ActiveRecord, assim como o Django pressupõe que você usará o ORM do Django – que eu penso que já merecia um nome. O admin do Django depende de você usar o ORM do Django. É até possível que você use SQLAlchemy com o Django, mas perderá o admin, que é uma ferramenta poderosa. Essa á uma decisão mais ou menos incontestável que o framework tomou por você.
Já com o Pylons, a quantidade de decisões que o framework toma é miníma. A premissa básica é que tudo gira em torno de WSGI e seus middlewares. WSGI define um padrão de comunicação entre o servidor web que você for usar (por exemplo, o Apache) e o framework que você for usar. Mas também define que diversas camadas de possam ser encapsuladas dentro da sua aplicação antes da resposta ser entre ao servidor. Esse é um ponto central no Pylons, tão central atualmente que o controlador básico do Pylons é o WSGIController e todos os seus controladores estendem dele.
Fora isso, o seu projeto criado com o Pylons tem uma pasta model, mas não define se você deve usar SQLAlchemy, Storm ou a DB-API diretamente. O SQLAlchemy trabalha com o padrão DataMapper e você não gosta disso? Tudo bem, você pode escolher usar o Elixir, uma pequena camada que empacota o SQLAlchemy como ActiveRecord. Pylons não opta por nenhuma biblioteca JavaScript, embora o módulo Paginator possua extensões para as principais bibliotecas de JavaScript disponíveis atualmente. Não existe uma forma padrão de se construir formulários. Você pode ir desde o simples HTML, sendo validado com formencode, passando por ToscaWidgets e chegando até o formalchemy, mas nada disso é obrigatório. Você pode usar o Authkit como uma forma de implementar autenticação – e fique avisado que ele tem uma má-fama na comunidade, pelo menos no canal #pylons do FreeNode –, ou pode implantar a sua própria forma de autenticação. Como template, você pode escolher entre Mako, Genshi, Jinja, Kid, Cheetah. Como você pode ver, cada projeto Pylons pode ser bem diferente do outro.
Parece um pouco perigoso caminhar com tantas variáveis no caminho, ainda mais que no geral a funcionalidade ganha com isso seja pouca. E obviamente eu não o único preocupado com isso. Recentemente surgiu uma discussão sobre integridade conceitual, e de como o Django e o Pylons atingem ou não tal alvo. Eu ainda penso que é possível manter um framework plugável e atingir a tal da integridade conceitual. No mais, não existe magia negra no Pylons. e você tem a sensação de estar trabalhando com Python mesmo. Mas, como você viu acima, provavelmente estamos falando mais a respeito de um meta-framework do que de um framework completo. E isso pra mim é bom.
Um dos problemas atuais do Pylons é a relativa falta de estabilidade de suas APIS. Isso é parcialmente explicado pelo fato de ser versão 0.x ainda, e o fato de que muitas APIs dos componentes que ele agrega estão mudando. Algumas APIs que foram adaptadas do Rails form implementadas de forma pouco "pitônica" ou tem alguns problemas estruturais e vão mudar também (Routes e WebHelpers). É preciso estar dentro da lista de discussão, no IRC pra poder acompanhar o que está acontecendo.
A documentação não é ruim, mas com a mudança das APIs, ela se desatualiza rapidamente. E como o projeto agrega outros, muitas vezes você precisa visitar diversos sites até achar ou criar sua solução. Não chega a ser um empecilho, já que não são muitos lugares onde se preocupar (minhas principais dúvidas acabam girando entre o próprio Pylons e SQLAlchemy), mas pode frustrar os mais ansiosos. Com a versão 0.97 será possível criar um projeto já utilizando SQLAlchemy, que eu penso que tem tudo pra se tornar o padrão oficial do Pylons.
WSGI é uma parte interessantíssima. Na comunidade internacional, tem se falado mais de componentes WSGI do que middlewares, já que as aplicações tem se tornado mais e mais dependentes desses middlewares, e isso faz todo o sentido. Um exemplo do que pode ser feito com WSGI: com versões anteriores do ToscaWidgets, para que eles funcionassem e tivessem a aparência correta, era preciso inserir no seu template a chamada aos Javascripts e CSS do ToscaWidgets. Com as últimas versões, ao adicionar o middleware do ToscaWidgets, você especifica se quer que ele injete os recursos no seu HTML. Um avanço interessante, e um bom exemplo do que pode ser feito através dos middlewares WSGI. O Django inclui o conceito de middlewares, de forma um tanto quanto parecida com os middlewares WSGI.
Veja como ficaria esse exemplo, ao configurar os middlewares
# The Pylons WSGI app
app = PylonsApp()
# CUSTOM MIDDLEWARE HERE (filtered by error handling middlewares)
host_framework = PylonsHostFramework(default_view="mako")
app = TGWidgetsMiddleware(app, host_framework, inject_resources=True)
Podemos embutir uma aplicação que fale WSGI como um controller no Pylons – como por exemplo, o Trac ou o MoinMoin. Muita coisa no Python está convergindo para WSGI: o antes monolítico Zope, na versão 3 foi quebrado em vários componentes e tem alguma integração com WSGI, embora eu não saiba dizer no momento como isso é feito. Django e TurboGears também falam WSGI, mas no Pylons isso está bem mais explícito, para o bem e para o mal.
Uma coisa que eu gostaria de ter feito e ainda não fiz são alguns experimentos com REST no Pylons. O deploy de uma aplicação WSGI sobre o Apache, usando FastCGI ou CGI não é complexo. Ainda não testei o mod_wsgi. Mas algumas coisas podem acontecer. Recentemente mudei minha aplicação para usar OpenID. Rodando ela no servidor do Paste, tudo correu bem. Ao fazer o deploy usando Apache, WSGI e Flup, um erro ocorreu. Após alguma pesquisa e ajuda no #pylons, descobri que o authkit está retornando um tamanho de página como inteiro, ao passo que o Flup esperava uma string. Uma modificação fácil de ser feita, mas que no mínimo provou que o Authkit nunca foi testado nesse ambiente.
Tendo dito isso, hoje o Pylons pode não ser o framework para a comunidade Python por uma série de razões, mas é o framework para mim.
Links sobre a discussão sobre integridade Conceitual
]]>
