[IMP] Library pattern and standards #23
Conversation
…texto [FIX] Grammar on README.
…asicos dos eventos
|
Valeu pelo PR @mileo porem eu nao concordo com uma boa parte desse PR na forma como ta. Basicamente aumenta de forma muito significativa o "empacotamento" do projeto de forma não relevante. Ter esse tanto de arquivos de blablabla para um projeto como Odoo tudo bem, numa lib que foi gerida com 200 linhas de codigo manual, eu ja acho totalmente abusivo;
Alem, disso como a nova politica do Travis, é bem possível que mudamos a CI do projeto. ai não fica legal atrelar tanta coisa ao Travis antes dessa possível mudança. |
|
Todas as libs que são mantidas pelo erpbrasil estão nesse padrão, ter um padrão único facilita quem quer contribuir e ajuda a gente a mantermos somente uma documentação de como contribuir. Testar em várias versões do Python é uma boa forma de nos anteciparmos aos problemas e como a lib é auto gerada isso vai rodar poucas vezes por ano. O Tox tb facilita rodar os testes localmente com virtualenvs com diversas versões do Python. Tb tenho usado bastante o github workflows em alguns projetos e é bem interessante, quando for possível fazemos isso para as libs do erpbrasil e ai será uma mudança em todas as libs. Sei que parece muita coisa, mas facilita bastante a manutenção de várias libs ao mesmo tempo, por exemplo surgiu uma versão do python nova e queremos colocar ela nos testes, com todas as libs no mesmo padrão não tem segredo. Se encontrarmos um bug no generateDS e precisarmos regerar todas as libs: nfe / ginfes / dsf / issnet e etc, fazemos isso e fechamos uma versão pra cada uma em poucos minutos. A questão do Windows é algo discutível, não precisamos realmente manter a lib 100% operacional no windows, mas na semana passada por exemplo no telegram do erpbrasil https://t.me/erpbrasil apareceu um usuário Windows, querendo contribuir. |
Sera? Vc chama isso de examplo? Peguei as principais libs da org erpbrasil onde vcs botaram esses "padroes" de teste, francamente se eu sou uma pessoa procurando avaliar o serio do projeto isso não me passa segurança:
Acho mais ou menos, quando fiz esse PR erpbrasil/erpbrasil.edoc#30 o Tox me fez perder muito tempo pelo contrario. Em situaçoes de lib complexas com dependencias nativas, como a lib erpbrasil.assinatura, eu acho super valido, mas em outras situaçoes acho mais um complexidade desnecessaria.
O problema é que vc acha que qualquer um pode fazer evoluir essas libs. E ai afogando o codigo relevante dentro do pacote maior do que a lib em se mesmo, vc passa sim essa imagem. So que é falsa! Tudo bem que a KMEE da manutençao sem problema nas lib erpbrasil.base, erpbrasil.edoc, edoc.pdf ou assinatura. Mas essas libs com generateDS é um examplo tipico onde vcs pensaram fazer bem sem pensar muito, se seguraram no pacote em vez da substancia mas não hesitaram em misturar código gerido com ajustes manuais, diff enormes a cada commit com impossibilidade de rastrear as mudanças, o que quase faz perder o beneficio de usar um gerador de código, ja que vc nao sabe mais o que é gerido de forma automático, o que nao é, como se atualiza as coisas... Sou bem aberto em melhorar o empacotamento, mas pacote 10x maior do que a fonte da lib tenho minhas reservas. |
|
@rvalyi depois da uma olhada mas todos os testes linux/travis desses projetos estão pegando. Por exemplo:
Os do windows não são prioritários, eu nem tenho como testar, quando é algo trivial tento corrigir.
|
Não posso negar que sou a favor de padronização. 😄
Eu deixaria a questão do windows para tratar em outro momento. Sobre os demais itens como bumpversion e tox nunca mexi e portanto não tenho como opinar. Porém, posso dizer que não saberia lidar com os problemas ligados a estes itens. |
|
Tox ele praticamente simula o teste do Travis na sua máquina, então ajuda muito vc não ficar tendo que esperar rodar. Basta vc dar um pip install tox, e acessar a pasta do projeto e rodar o comando tox. Ele roda todos os testes cada um em um virtualenv separado. No nosso caso vc vai precisar ter várias versões do python instalado na sua máquina... Resolvido isso, tudo vai tranquilo. O bumpversion é tipo o comando que rodamos no ocabot bumpversion major Ele commita, muda as versões nos lugares e cria as tags Depois para publicar é só seguir os passos do Wiki |
Certo.. Eu fico extremamente ansioso esperando o travis rodar :D
Entendi
Boa.
Ahh legal.. vou dar uma olhada na wiki. |
|
pessoal, com pystest precisa esperar Travis nao, so fazer Alem disso a gente nao faz isso no Odoo de testar com 4 Pythons diferentes e no Windows tb, meio chato ter que fazer nas libs. Ate onde eu vejo quase ninguem que faz libs Python usadas no codigo da OCA parte para isso tb nao. A meu ver ter os testes passando e a lib feita correctamente era bem mais importante do que partir para esse ceremonial todo, novamente botando o pacote na frente do conteudo, o que diz muito tb... |
|
outra coisa, so um um Vamos la, imagine que vc ta no 0.1% de chance que uma lib assim sem dependencia nao funciona com uma dessas versoes do Python. Ainda assim, o Travis vai detetar, sem obrigar cada usuario que ja tem Python instalado a ter que instalar 4 runtimes, rodar nos 4 runtimes e quebrar a cabeça com detalhes do Tox (tem detalhes sim, quando fiz o PR do edoc nao foi so instalar o tox para rodar). Quando peguei o repo do edoc.gen, os arquivos tox dele tavam tb todo zoado com milhares de links para acertar o que so passava uma imagem de projeto quebrado, assim como ta hoje o edoc.issnet por examplo. Entao desculpa mas nao vejo isso como algo super esperto nao... |
Pessoal adicionei algumas ferramentas e detalhes na biblioteca:
As libs abaixo já estão nesse padrão:
https://travis-ci.org/github/erpbrasil/nfselib.ginfes/builds/742688698
https://ci.appveyor.com/project/mileo/nfselib-ginfes/builds/36239385
https://codecov.io/github/erpbrasil/erpbrasil.base
E também conforme conversado mover a lib para o erpbrasil.
@rvalyi