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:
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.
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/
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
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,