Demos uma olhada na sua branch [remove-deps], estava quebrando pois a versão do django tinha sido atualizada para a 1.8 devido a mudança no setup.py de ==1.7.7 para >=1.7.7, assim como varias outras dependencias.
Deixar as dependencias com >= é mesmo uma boa opção? Ao que parece isto é um pouco perigoso.
Outro problema identificado foi a mudança do solr para o whoosh. Como havia sido comentado antigamente, o colab ainda possui aquele erro de campo duplicado ao ser utilizado junto ao colab. Ou seja, ao indexar qualquer dado, a página de pesquisa quebra pois o whoosh já possui um campo score que o colab define. Podem haver mais erros envolvendo o whoosh uma vez que isto não foi avaliado.
Acho melhor avaliar sobre a correção deste erro e corrigi-lo antes de tirár de vez o solr das dependencias. O que acha?
E como o banco padrão do colab agora será o sqlite, removendo as dependencias postgres, deve-se lembrar desta mudança ao construir o novo pacote do colab e nas configurações do colab do chef.
Como o Colab agora não é uma app mas sim um framework o ideal é mantermos ele o mais compatível possível com diferentes versões.
Neste caso o ideal é que utilizemos django 1.7 ou maior mesmo e lidemos com as diferenças de versões no código (assim como fazemos com as versões do Python no django-revproxy.
Sobre o Whoosh a ideia é não depender exclusivamente de um buscar monstro como é o caso do Solr. Pra isso vamos precisar sim levantar quais são os pontos de incompatibilidade com o whoosh.
Essas mudanças estão na master e idéia é que estejam maduras para a próxima release, acredito que temos tempo hábil.
Sobre o pacote, o nosso pacote do colab no momento é exclusivamente nosso. No caso do SPB vamos continuar a utilizar o postgresql. Neste caso a equipe de devops vai precisar decidir se a responsabilidade de fazer essas configs vai ser do pacote do colab ou do chef. Quando fizemos essa alteração já demos um ping no Matheus.
Se não conseguirmos corrigir os testes todos agora pelo menos eles vão ser de grande ajuda no refactor para encontrarmos os erros, certo?
Abraços,
-- Sergio Oliveira
2015-06-15 17:52 GMT-03:00 Gustavo Jaruga Cruz :
> Caro Sergio, > > Demos uma olhada na sua branch [remove-deps], estava quebrando pois a > versão do django tinha sido atualizada para a 1.8 devido a mudança no > setup.py de ==1.7.7 para >=1.7.7, assim como varias outras dependencias. > > Deixar as dependencias com >= é mesmo uma boa opção? Ao que parece isto é > um pouco perigoso. > > Outro problema identificado foi a mudança do solr para o whoosh. Como > havia sido comentado antigamente, o colab ainda possui aquele erro de campo > duplicado ao ser utilizado junto ao colab. Ou seja, ao indexar qualquer > dado, a página de pesquisa quebra pois o whoosh já possui um campo score > que o colab define. Podem haver mais erros envolvendo o whoosh uma vez que > isto não foi avaliado. > > Acho melhor avaliar sobre a correção deste erro e corrigi-lo antes de > tirár de vez o solr das dependencias. O que acha? > > E como o banco padrão do colab agora será o sqlite, removendo as > dependencias postgres, deve-se lembrar desta mudança ao construir o novo > pacote do colab e nas configurações do colab do chef. > > > -- > -Gust >
Eu concordo com tirar o solr e arrumar o colab para o whoosh e sobre o pacote.
Mas se formos deixar o django com versão '>=', como trataremos isto? Atualmente o que está quebrando do django 1.8 são apps externos e não o próprio colab, acho esta tática um pouco perigosa de se utilizar na master do colab, uma vez que toda hora que o django lançar uma versão major deveremos aguardar os aplicativos externos realizarem suas mudanças para se adequarem ou aceitarem MR nossos caso nos propunhamos a fazer-los.
Os testes nós conseguimos rodar e aparentemente todos passaram após alterar a versão do django para a 1.7.7. Apesar deque pensando agora provavelmente as configurações de testes ainda estavam usando o solr ao invés do whoosh e por isto que os testes relativos a indexação de dados funcionaram.
Da pra lidar com essa mudança das versões do Django sim Jaruga. O django-revproxy funciona com o 1.6, 1.7 e 1.8. Claro que não da pra manter versões muito antigas. O que da pra fazer por enquanto é usar Django>=1.7,<1.8 e trabalharmos na compatibilidade com o 1.8. Quando estiver compativel mudamos para Django>=1.7,<1.9.
Pra isso precisamos colocar o tox no colab e precisamos mudar o .travis.yml pra fazer matrix de build combinando as versões.
--
Sergio Oliveira
2015-06-15 19:39 GMT-03:00 Gustavo Jaruga Cruz :
> Fala sérgio, > > Eu concordo com tirar o solr e arrumar o colab para o whoosh e sobre o > pacote. > > Mas se formos deixar o django com versão '>=', como trataremos isto? > Atualmente o que está quebrando do django 1.8 são apps externos e não o > próprio colab, acho esta tática um pouco perigosa de se utilizar na master > do colab, uma vez que toda hora que o django lançar uma versão major > deveremos aguardar os aplicativos externos realizarem suas mudanças para se > adequarem ou aceitarem MR nossos caso nos propunhamos a fazer-los. > > Os testes nós conseguimos rodar e aparentemente todos passaram após > alterar a versão do django para a 1.7.7. Apesar deque pensando agora > provavelmente as configurações de testes ainda estavam usando o solr ao > invés do whoosh e por isto que os testes relativos a indexação de dados > funcionaram. > > -Gust >
Gustavo Jaruga Cruz
Sergio Oliveira