A quem interessar possa, o MexApi agora é gerado pelo Pelican 3.3. Deu menos trabalho do que eu imaginei que daria, uma vez que algumas coisas foram alteradas, como a API e, principalmente, o modo como os links para conteúdo interno (imagens) devem ser escritos. De qualquer modo, esbarrei em alguns percalços e é sobre eles que vou comentar brevemente.

Sobre as alterações requeridas pela atualização do Pelican 3.2 para o 3.3 em si, acho melhor você dar uma olhada nos três commits relativos a ela no meu GitHub: 85f5d04c40, 8220cf20d2 e f79d730c2d. Eles são mais elucidativos do que eu ficar falando merda aqui.

Em linhas gerais, o processo que utilizei para facilitar o upgrade foi o seguinte:

  1. Clonei todo o repositório do MexApi em um novo diretório;
  2. Criei um novo virtualenv e virtual host para a atualização dos pacotes e verificações;
  3. Instalei os pacotes do stable-req.txt antigo no novo virtualenv;
  4. Atualizei os pacotes no virtualenv novo;
  5. Verifiquei e arrumei o que deu pau;
  6. Commitei as alterações;
  7. Atualizei o diretório de sempre do MexApi com os novos commits;
  8. Atualizei os pacotes;
  9. Arrumei os artigos que contém imagens e o Makefile;
  10. Publiquei já com o Pelican 3.3.

Não vou detalhar cada passo do processo porque, além de ser chato, cada um pode (e deve) fazer do seu jeito. Mas alguns macetinhos que usei podem facilitar a vida de quem resolver fazer a mesma coisa.

Os dois primeiros desses macetinhos estão no passo 2: ao criar um novo ambiente de desenvolvimento, fiquei livre para testar a vontade. Caso eu tivesse feito alguma cagada irrecuperável, bastava apagar tudo e começar novamente sem colocar em risco o ambiente original que estava funcionando direitinho (e continua assim).

Já no passo 4, eu poderia atualizar os pacotes do python com o comando pip install -U [nome_do_pacote]. O virtualenv do Pelican tem 29 pacotes. Seria um pé na bola esquerda atualizar um por um. Daí eu fiz isso:

pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | \
xargs pip install --allow-external PIL --allow-insecure PIL -U

Esse comando percorre cada entrada da listagem do pip freeze, remove o lixo e atualiza tudo em um tapa só.

O passo 5 foi o que me deu mais trabalho. O meu tema usa um objeto que não existe no Pelican, aliás, #putaquepariunãoterissonopelicanainda! Esse objeto lê e guarda a hora da última modificação do arquivo com o artigo no disco. O tema depois usa isso para gerar uma tag apropriada com essa informação. Pra fazer isso funcionar eu precisei fazer um patch no Pelican 3.2. E claro que com o Pelican 3.3 esse patch parou de funcionar. Como python não é o meu idioma natural, eu penei umas 2h para encontrar onde eu poderia implementar o meu objeto. Achei e o patch está aqui.

Todos os demais filtros do Jinja2, plugins do Pelican e demais personalizações do tema do MexApi que eu já havia feito funcionaram bem com o novo Pelican, com exceção do [Better Figures & Images Plugin] []. Mas esse foi só atualizar com o código que o meu camarada Duncan Lock já disponibilizou.

Depois de tudo commitado (esse deve ser o anglicismo mais tosco do mundo tecnológico, commitado, vomitado...) e o ambiente final atualizado usando a mesma técnica do pip install -U acima, foi a hora de alterar os links para as imagens no passo 9. Eu poderia fazer tudo na mão, mas hey! Estou no Linux e tenho o sed. Daí fiz isso:

sed -i 's/\/static/\{filename\}/g' *.rst

Consertou tudo! Rá! ;)

Ainda no passo 9, quando fui rodar o make publish para gerar a versão final do MexApi para enivar para o GitHub Pages, me deparei com isso:

CRITICAL: 'ascii' codec can't decode byte 0xe2 in position 5874: ordinal not in range(128)

O interessante é que o make html roda redondo. Esse pau só dá no publish. Mais interessante ainda é que se eu rodar o Pelican em modo debug (pelican -D), o pau não aparece. Procurei algum bug report a respeito no GitHub do Pelican e não achei nada. Verfiquei meu tema e nada. E como o debug roda lindo até o final e sem erros, eu não consigo pegar o traceback do erro para ver onde está o problema. Enfim, depois de gastar um tempo tentando resolver isso sem sucesso, minha solução foi prosaica: alterei o Makefile para rodar o publish em modo de debug.1

Depois foi só make github e pronto. MexApi no Pelican 3.3 publicado no GitHub Pages.

Agora já posso começar a tratar o backlog de artigos (esse é um deles) e a fazer as atualizações incrementais no tema do MexApi que quero há algum tempo.

Ah, com esse artigo eu começo a escrever em Markdown2. Tenho escrito bastante em Markdown por causa do GitHub e as vezes me confundo com as sintaxes quando vou escrever aqui, em reStructuredText. O .rst é legal também, mas depois de conhecê-lo mais por causa do MexApi, tenho achado-o meio burocrático para coisas simples. O Markdown é mais direto ao ponto e limpo para ler sem processamento, sem contar que o suporte a realce de sintaxe dele é melhor nos editores de texto em geral.


  1. (29/05/2014) Encontrei a causa. O Makefile não tinha nada a ver com o peixe. O problema era que o publishconf.py habilita o plugin assets do Pelican. Na hora do make publish, o template usa o assets para minificar o CSS. Por sua vez, o assets estava configurado para usar o filtro cssprefixer, que altera as folhas de estilo para incluir regras específicas dos fabricantes no CSS. Daí eu li isso no GitHub do assets:

    Pelican's debug mode is propagated to Webassets to disable asset packaging and instead work with the uncompressed assets.

    Ou seja, habilitando o debug do Pelican como eu havia feito, eu desliguei o assets sem saber e por isso funcionou o publish. Mas foi uma solução porca.

    A partir daí foi fácil descobrir quem era o culpado. Para resolver o problema do jeito certo, e já que não uso e sou contra as regras de CSS por fabricante, eu removi o filtro cssprefixer do assets e retornei o Makefile ao que era antes. Agora está tudo bem, com o CSS minificado e o Pelican sem precisar rodar em modo de debug. Veja o commit da correção

  2. (29/05/2014) Não foi dessa vez. Aqui eu explico por quê.