devlog

Sei que a notícia do momento no mundo dos gerenciadores de código fonte é a mudança do repositório do rails do svn para o git, mas não poderia deixar passar em branco: o mercurial, um scm feito em python e que eu tenho usado pra algumas coisas chegou à sua versão 1.0 e agora pode ser instalado via easy_install. Muito bom!

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

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

• Questionamento de Adam Gona
• Resposta de Mike Ramm
• Resposta de James Bennet
• Considerações de Marcus Cavanaugh

Hoje, esse espaço aqui faz dois anos!

O primeiro post falava um pouco sobre Lua. Comecei direto, sem apresentação. Já tinha o waltercruz.com há algum tempo, e comecei o devlog como um braço nerd dele. Hoje, praticamente o devlog é o meu blog principal. Aliás, nas primeiras versões ele se chamava vardump. Até que eu vi que já existia um blog com esse nome, então resolvi mudar.

Uma época boa registrada aqui! Aprendi bastante sobre javascript e banco de dados. Aprendi realmente python (python foi provavelmente a minha primeira linguagem, mas não havia me aprofundado nela como deveria. Hoje, me arrependo de ter demorado).

Flertei um pouco com o Rails, com o Django. Nesse momento, meu framework escolhido e o que venho estudando com mais afinco é o Pylons. Até botei uma aplicação online com ele já!

Fiz uma porção de amigos, aprendi uma porrada de coisas. Lancei um outro blog sobre o cms desse site, o b2evolution. Hoje participo do desenvolvimento dele.

Mas gostaria de aproveitar esse post para uma coisa mais além da comemoração. Gostaria de perguntar: o que você acha que pode melhorar aqui? Uma das coisas que pretendo fazer é expor mais minhas opniões: o que eu gosto na programação, o que eu não gosto, e os porquês disso. Aproveitem os comentários!

Esse fim de semana eu estava mexendo como Pylons, mais exatamente tentando fazer o deployment de uma micro-aplicação feita com ele. Como me enrolei todo com o FastCGI, eu acabei tendo tempo de ler um pouco sobre WSGI.

WSGI é uma especificação de comunicação entre servidores web e servidores de aplicação. Pondo de forma grotesca: é como o seu aplicativo em TurboGears ou Pylons se comunica com o Apache, Lighttpd ou qualquer outro servidor. O Cacilhas fez uma implementação de WSGI pra Lua. Na trilha disso, eu dei uma pesquisada e achei o Rack - uma especificação semelhante para o Ruby.

Christian Neukirchen fez um post introdutório sobre o rack onde ele menciona dois frameworks, o Camping e o Ramaze, que já suportam o rack. Como vocês podem ver, o Camping é mais um produto do why the lucky stiff, famoso pelo Poignant Guide to Ruby.

Não cheguei a ver os frameworks - deixo esse trabalho a vocês. Mas vi pelo menos uma coisa interessante:

O Camping usa Ruby pra gerar os templates! Um exemplo, retirado do próprio site do projeto:

Esquisito? É porque vocês não viram o HAML ainda.

Eu não imaginava que a selva de templates tivesse chegado ao mundo Ruby, mas a página do Ramaze diz que ele suporta 7 templates engines. E não devem ser todas que existem! Será que já existe ZPT pra Ruby? O jeito é continuar com o bom e velho Erb.

Voltando ao Pylons, eu acabei conseguindo me virar com o CGI/FastCGI na segunda-feira. E com ele também não falta opção de escolha: o sistema de templates padrão é o Myghty, mas em breve será trocado para o Mako.

Talvez eu escreva um tutorial sobre Pylons, mas não estou prometendo nada. Mas acho que já testei o suficiente pra dizer que dos frameworks disponíveis pra Python, o que eu achei mais interessante foi ele.