devlog

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

1. Rum - Um 'gerador de CRUD para SQLAlchemy, feito pelo Alberto Valverde.
2. Uma introdução ao WSGI - Ian Bicking
3. WSGI - a resposta para a questão definitiva sobre Python, a web e tudo mais? - Humberto Diógenes
4. Pylons Book Livro sobre o Pylons (em fase de escrita ainda)
5. Documentação do TurboGears 2
6. Documentação da versão 0.97 do Pylons

Sandbox e limitações

À semelhança do zope, o appengine oferece uma sandbox. Você tem um runtime do Python 2.5.2, mas algumas coisas estão limitadas: escrita em filesystem é proibida, alguns módulos não podem ser importados, e toda a comunicação com o mundo externo só pode ser feita através da urlfetch, e fazendo apenas requisiçõs HTTP e HTTPS (portas 80 e 443). Curiosamente, na primeira versão, mesmo a execução das APIS do gdata eram impossíveis dentro do appengine, mas logo depois eles liberaram uma nova versão com suporte a requisições através do urlfetch. Não é possível executar um subprocesso, nem executar tarefas agendadas. É um impacto razoavelmente pequeno, mas ainda assim presente.

Você pode enviar apenas 1000 arquivos no máximo. Parece muito, mas é um limite fácil de ser batido. E como não tem zipimport lá ainda, fica difícil de enviar os eggs compactados. Não chega a afetar os usuários do Django, que já tem uma versão do Django lá e não precisam enviar o Django em si, mas usuários que queiram testar outros frameworks, acabam tendo o espaço seriamente comprometido. Aliás, não existe uma forma prática de rodar outro framework, principalmente um que seja centrado em eggs, como o Pylons, devido à restrição de módulos. Ian Bicking criou um projeto chamado App Engine Monkey, que basicamente, permite o uso de eggs (não compactados) no AppEngine. Através dele é possível rodar Pylons, e possivelmente, outros frameworks.

É possível enviar seus próprios pacotes e bibliotecas para o appengine, com a exceção de que eles não usem módulos implementados em C, ou seja: apenas puro python.

Bugs no SDK

É interessante, alguns bugs acontecem no SDK apenas, mas não no servidor de produção. Mas você tem de aplicar alguns patches no seu SDK para se livrar dos bugs!

A importação de objetos em massa (bulkloader) usa o módulo csv do Python. Mas o módulo csv não tem suporte a UTF-8. É possível corrigir esse problema aplicando no SDK o patch descrito no bug 157. Isso resolve a importação no SDK, mas não no servidor de desenvolvimento.

Os cabeçalhos das requisições vem sempre em minúsculas. No meu caso, o gdata estava esperando por Location, mas recebeu location. Um caso simples de resolver.

Ao fazer requisições com o urlfetch, os parâmetros de querystring não são enviados. É um bug que afeta só o SDK, e também simples de resolver.

Django

O suporte a Django é builtin, mas devido a própria estrutura do Django algumas coisas não funcionarão como um Django comum. Por exemplo, o admin do Django depende dos models do Django. Como no AppEngine, estamos amarrados ao próprio banco do Google, o admin fica de fora. Logo, fica de fora uma característica utilissima do Django: a serialização de um objeto do Model em JSON.

Assim como surgiu o projeto para rodar o Pylons no AppEngine, existe um outro projeto, que permite que o Django seja mais Django no Appengine, com a possibilidade de executar a maioria dos comandos do manage.py, traz de volta a serialização de modelos pra JSON e torna possível o envio de e-mails usando a própria API do Django.

A parte boa

O logging funciona, muito bem por sinal, e a tela para visualizar os logs da sua aplicação é bem intuitiva. Resta ainda toda a discussão de se deixar os dados no google é bacana ou não. As restrições as vezes enchem, mas com um pouco de paciência, é possível chegar à uma convivência amigável com o AppEngine.