Pular para o conteúdo principal

Como explodir seu buildout com Plone 2.5 e Five 1.4?

Já faz algum tempo que a melhor forma de realizar deploy de projetos Plone passou a ser a utilização da ferramenta zc.buildout, também chamada apenas de buildout. É realmente incrível como ela facilita a tarefa de criar ambientes tanto para produção como desenvolvimento de forma simples, rápida e fácil, mesmo nos mais complexos cenários.

Tudo isso graças a sua arquitetura, a qual permite a utilização de diferentes receitas (recipes), desde que elas sejam publicadas como um pacote Python no PyPi, e assim podem ser reutilizadas por qualquer um que necessite da mesma funcionalidade. Na verdade, o buildout pode (e deve) ser usado por quaisquer projetos, não se limitando apenas ao Zope e seus compatriotas como o Plone e Grok, e já vem sendo usado em projetos Django também.

Porém, existem vantagens e desvantagens de se utilizar o buildout para o deploy de projetos de software. Na minha opinião, as vantagens são muito maiores que as desvantagens. A principal vantagem é a capacidade de se criar ambientes de forma controlada, facéis de serem reproduzidos e estáveis (a depender da configuração usada). E a principal desvantagem é a dependência da ferramenta (buildout) sem ter conhecimento de como o deploy do ambiente funciona a ponto de poder identificar e reparar as falhas e problemas que ocorrem quando algum conflito, atualização de pacote ou incompatibilidade interferem no seu funcionamento.

De fato, existem armadilhas que podem ocorrer e acredito que muitos usuários do buildout já devem ter odiado ele quando as coisas começam a dar errado e não se sabe por que. Ontem mesmo que recebi um email de um amigo, relatando um problema com o buildout, e por incrível coincidência, ele já havia ocorrido comigo, por isso, eu já tinha a solução.

Foi então que percebi que era hora de compartilhar o problema e a solução a fim de ajudar qualquer um que venha a se deparar com essa situação no futuro. O cenário é o seguinte: instalação do Plone 2.5 (e Zope 2.9) com buildout, porém utilizando o Five 1.4 ao invés do Five 1.3 que vem originalmente com o Zope 2.9.

A armadilha é a seguinte: quando modificamos a versão do Five, não estamos fazendo nada de errado, pois a versão 1.4 foi feita para ser compatível com o Zope 2.9. Esse é também um pré requisito para diversos pacotes adicionais do Plone que necessitam de funcionlidades da ZCA e do Framework Zope 3 que não são suportados pela versão 1.3 do Five.

Porém, a receita de instalação do Zope para o Plone 2.5 (plone.recipe.zope2instance), não está preparada para essa situação e o sintoma do problema apenas aparece na tentativa de iniciar ou reiniciar a instância, gerando uma falha na localização de algumas diretivas ZCML, como por exemplo:

ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/genericsetup', u'registerProfile')

De fato, quando um erro como esse ocorre, fica difícil identificar qual é a real causa. Nesse momento é que odiamos o buildout com todas as forças. Mas não se desespere, existe luz no fim do tunel! Ao investigar a situação a fundo descobri uma forma simples, fácil e indolor de evitar quaisquer surpresas em ambientes Plone 2.5 com Five 1.4, apenas adicionando as seguintes linhas ao seu arquivo buildout.cfg:

[commands]
recipe = plone.recipe.command
command =

cp ${productdistros:location}/Five/skel/site.zcml ${instance:location}/etc


Não se esqueça também de incluir a seção "commands" depois de "instance" na seção principal do buildout.cfg.
Essa configuração assume que você esteja instalando o Five 1.4 em [productdistros] usando seu link para download e instalação automática.

Como pode ser observado pelo trecho acima, estamos usando a receita plone.recipe.command que nos permite executar qualquer tipo de comando shell para copiar a versão correta (que vem com o Five 1.4) do arquivo site.zcml para o diretório etc da instância Zope. A depender da configuração das suas instâncias, pode ser necessário ajustar o comando, assim como, se você já possui uma versão especial de configuração do arquivo site.zcml, o comando também deve ficar diferente.

Espero que essa dica ajude outras pessoas a conhecer o buildout e a resolver e evitar esse tipo de problemas em ambientes com o Plone 2.5 e Five 1.4, e de quebra, serva como um exemplo de utilização da receita plone.recipe.command.

Comentários

Anônimo disse…
Você já tentou virtualenv http://arthurkoziel.com/2008/10/22/working-virtualenv/
Sim! Eu uso virtualenv também mas isso não resolve o problema mencionando nesse post.

Eu vou postar um outro artigo com uma introdução sobre como criar um buildout simples com virutualenv para desenvolver projetos de software em Python.

Sds,

Postagens mais visitadas deste blog

18 de junho agora é #dornelesday

Hoje é um dia muito especial, pois hoje é dia de homenagear uma grande pessoa: Dorneles Treméa. Pois ele, com seus gestos simples, paciência, perseverança e generosidade, se tornou um exemplo para muitas pessoas, no mundo todo, dentro da comunidade de Software Livre e mais especificamente na comunidade Python e Plone. Apesar de ter nos deixado tão jovem, o tempo é relativo, por isso, tenho certeza que ele deixou uma marca profunda na vida de todos que conviveram com ele. Seja pela paz e alegria que ele transmitia, sempre de bom humor nas mais difíceis situações, seja pela disposição eu ajudar quem lhe pedia auxílio, seja pela dedicação que tinha pela sua família. Por isso, para mim e para muitas pessoas, o dia 18 de junho é a partir de hoje #dornelesday, que representa um dia para refletir sobre tudo de bom que nosso colega e amigo trouxe para nós com seu exemplo de vida. Que todo dia possamos nos inspirar com esse exemplo e possamos aprender, um pouco que seja, com este legado. Na ver

Social Network Research and Plone

I will have the next 6 months to develop a framework to help fast delivery of S ocial Network Services - SNS , it's the implementation task of my final work graduate research and has the title: Social Network Services: component based framework. And, because I have been using Plone in some projects to deliver Content Management Applications, like: company and community web sites, intranets, etc, in the last three years (ruda_porto IRC nick), I decide to use it as a base system to construct a SNS application framework. Of course that is not a simple task, since Social Networks Services Applications can be used for friendship, academic, professional or some kind of specialized networks, but the central point will be study the hole application domain (problem scope) and implement a framework (solution scope) to abstract social network core objects and features in a way it will be easy to extend and integrate with Plone content management core products and other third-part products fo

RelStorage: ZODB usando backend relacional (SGDBs)

Introdução O ZODB (banco de dados orientado à objetos para aplicalções Python ), originalmente criado como um componente do servidor de Aplicação Zope2 ( Z Object Publishing Environment ) , foi desenvolvido com o conceito de "Storage Layer", o qual abstrai o tipo de backend responsável pela persistência dos objetos. Historicamente, o primeiro Storage Layer desenvolvido para o ZODB foi FileStorage, que tem como objetivo ser simples e robusto, e por isso armazena todos os objetos e transações um único arquivo de forma sequencial. Para acessar os objetos através do seu caminho na hieraquia de objetos do ZODB (ex: obj2 = root['obj1']['obj2'] ), o FileStorage cria um arquivo auxiliar de índice e que deve estar completamente na memória para que o desempenho seja adequado. Compartilhando o ZODB Mais tarde, devido a necessidade de compartilhar um mesmo banco de dados por diversas instâncias de uma aplicação (ou diversas aplicações), foi desenvolvido o ZEO (Zope Ente