O que é o django.contrib?
Jacob Kaplan-Moss adicionou em seu blog um post interessante com algumas considerações sobre o django-contrib. Embora não seja uma declaração oficial da equipe de desenvolvimento do Django, é um texto bem interessante e lança alguma luz sobre o que podemos esperar do futuro do framework. Boa leitura!
O que é o Django Contrib?
por Jacob Kaplan-Moss
tradução de Walter Cruz
Já que é uma pergunta recorrente, eu pensei em gastar um tempinho escrevendo minhas idéias a respeito do que o django.contrib realmente é, e o que realmente significa a inclusão de um pacote nele.
Essa é apenas minha opnião pessoal — de fato, é por isso que eu postei aqui ao invés de adicionar esse conteúdo na documentação oficial do Django. Porém, a maior parte do core team do Django discutiu esse tópico extensivamente na DjangoCon, então eu estou bem seguro que há um certo consenso sobre essas idéias.
Em resumo, o django.contrib contém implementações opcionais e padronizadas de padrões comuns. Isso é:
- Opcional: pacotes do contrib devem ser removíveis. Você deve ser capaz de executar um rm -rf django/contrib e o Django não deve quebrar.
Leitores astutos vão perceber que o django.contrib.contenttypes viola essa regra. Eu penso que isso deveria ser considerado um bug.
Com isso, os pacotes do django.contrib idealmente não devem ter "acesso especial" à qualquer coisa interna do Django — tudo o que um pacote do contrib faz deve ser possível de ser feito em um aplicativo externo. Novamente, leitores astutos irão notar que quebramos essas regras em alguns lugares, e, mais uma vez, isso deve ser considerado um bug.
- Padronizadas: tudo no contrib precisa ser geralmente aceito como a Forma Correta de fazer algo pela grande maioria dos usuários.
django.contrib.sessions é um exemplo disso. Existem muitas formas de lidar com sessções, mas a forma que o Django faz — um identificador de sessão opaco no cookie, com todos os dados armazenados no backend — é geralmente aceito como uma ótima prática. Sim, existem outros meios de implementar sessões — posso citar, por exemplo, cookies assinados — mas a técnica usada pelo django.contrib.sessions geralmente funciona para a maior parte dos usuários.
- Padrões Comuns: pacotes no contrib devem resolver problemas encontrados frequentemente por desenvolvedores web comuns. Então, eu gostaria de argumentar contra a inclusão de algo como o django-reversion. Ele é muito legal e eu o uso, mas o rastreamento de dados versionados nessa granularidade não é algo necessário na vasta maioria dos sites.
Bons pacotes do contrib devem tratar questões que não sejam triviais, que sejam propensas a muita discussão, e que sejam difíceis de fazer do modo certo para o caso comum. Queremos evitar que as pessoas precisem decidir entre dezessete frameworks de sessões diferentes, por exemplo.
Sobre o django.contrib.gis: ele não é exatamente um padrão comum, mas se você está lidando com dados geográficos, construindo em cima de ferramentas GIS existentes como o PostGIS e o GDAL, ele é ambos: o padrão comum e a melhor prática. Você poderia dizer que o django.contrib.gis implementa um padrão comum para uma classe menor de usuários, eu suponho. Mais importante, porém, é algo complicado de ter funcionando corretamente, então há um grande valor em te-lo funcionando.
É claro, existe um valor de marketing em ter algo no contrib. Certamente ajuda as Relações Públicas dizer que o "Django vem com suporte a GIS." Está na moda desdenhar das Relações Públicas no mundo opensource, mas eu seria falso em dizer que eu não uso o poder do contrib como uma ferramenta de marketing. Eu certamente o faço, e não tenho reservas em faze-lo.
Mas há um problema em trazer algo para o núcleo: isso impede inovação. Assim que nós "abençoamos" um pacote do contrib, reduzimos drastricamente o ímpeto de escrever bibliotecas competitivas. Assim, um bom pacote do contrib deve ter consenso geral, e deve ser bem maduro. É por isso que uma biblioteca de evolução de esquemas não estará presente no Django 1.1 a despeito de termos três ou quatro alternativas viáveis. Nenhuma dessas opções é claramente melhor, e todas estão evoluindo muito rápido. Devemos esperar para "aprovar" uma biblioteca até que tenhamos certeza de qual é a certa..
Outra desvantagem para a inclusão de pacotes no contrib é o acoplamento das funcionalidades dos pacotes com o ciclo de lançamentos do Django. Um pacote pequeno como o django-tagging pode adicionar funcionalidades rapidamente; limitar releases a cada seis ou nove meses iria retardar a sua divulgação enquanto usuários esperam por novas versões do Django para serem capazes de atualizar o pacote.
A inclusão de um pacote no contrib é também uma promessa de suporte futuro: nada seria pior que ter de remover um pacote do contrib em uma versão futura — queremos adicionar funcionalidade, não retirá-las! Porém, a adição de novos pacotes no contrib significa mais trabalho para os committers, então, um novo pacote realmente precisa trazer junto um novo contribuidor. Idealmente, um grupo de novos contribuidores: ter parte do código na mão de apenas um contribuidor não é uma boa idéia..