Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] Library pattern and standards #23

Open
wants to merge 29 commits into
base: master
Choose a base branch
from

Conversation

mileo
Copy link
Contributor

@mileo mileo commented Nov 11, 2020

Pessoal adicionei algumas ferramentas e detalhes na biblioteca:

  1. bumpversion;
  2. tox;
  3. Testes em diversas versões do python;
  4. coverage report;
  5. Testes no windows;
  6. Referências extras ao projeto erpbrasil;
  7. Facilidade para fechar versões e enviar para o pypi;
  8. Validador de sintaxe do setup.py;
  9. Validador de sintaxe da documentação;

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

image

E também conforme conversado mover a lib para o erpbrasil.
@rvalyi

@rvalyi
Copy link
Member

rvalyi commented Dec 6, 2020

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;
e assim chega a ser mais uma poluição do que outra coisa.

  • bumpversion -> uma dependencia para trocar uma referença unica de uma versao?
  • tox; -> a nfelib nao tem dependencia, o generateDS ja ta bem testado. Na pior pode testar em varias versoes facilemente sem tox com Travis ou uma outra ferramenta.
  • Testes em diversas versões do python; -> mesmo comentario
  • coverage report; -> pode ser
  • Testes no windows; -> é facil ter isso na CI sem accrescentar dependencia. Tb pouco necessario ja que nao tem dependencias, so Python basico.
  • Referências extras ao projeto erpbrasil;
  • Facilidade para fechar versões e enviar para o pypi;
  • Validador de sintaxe do setup.py;
  • Validador de sintaxe da documentação; -> desnesserio para uma documentaçao automatica como essa....

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.

@mileo
Copy link
Contributor Author

mileo commented Feb 1, 2021

@rvalyi

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.

@rvalyi
Copy link
Member

rvalyi commented Feb 1, 2021

@rvalyi

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.

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:

2021-02-01_19-36
2021-02-01_19-36_1
2021-02-01_19-36_2
2021-02-01_19-37
2021-02-01_19-37_1

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.

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.

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.

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.

@mileo
Copy link
Contributor Author

mileo commented Feb 2, 2021

@rvalyi depois da uma olhada mas todos os testes linux/travis desses projetos estão pegando.

Por exemplo:

image

Os do windows não são prioritários, eu nem tenho como testar, quando é algo trivial tento corrigir.

image

@marcelsavegnago
Copy link

@mileo

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.

Não posso negar que sou a favor de padronização. 😄

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.

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.

@mileo
Copy link
Contributor Author

mileo commented Feb 5, 2021

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

https://github.com/erpbrasil/erpbrasil.base/wiki

@marcelsavegnago
Copy link

Tox ele praticamente simula o teste do Travis na sua máquina, então ajuda muito vc não ficar tendo que esperar rodar.

Certo.. Eu fico extremamente ansioso esperando o travis rodar :D

Basta vc dar um pip install tox, e acessar a pasta do projeto e rodar o comando tox.

Entendi

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

Boa.

Depois para publicar é só seguir os passos do Wiki

https://github.com/erpbrasil/erpbrasil.base/wiki

Ahh legal.. vou dar uma olhada na wiki.

@rvalyi
Copy link
Member

rvalyi commented Feb 5, 2021

pessoal, com pystest precisa esperar Travis nao, so fazer pytest -s que ele ja roda, muito mais simples do que o tox.
uso muito 4G e disco SSD, essa coisa de ter que instalar 4 runtimes python para rodar os testes locais nao acho nada simples nao...

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.
O Openupgradelib fica se masturbando com Tox https://github.com/OCA/openupgradelib ? Nao fica nao e por ai vai. Ai que essa coisa de erpbrasil mostra seus limites...

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...

@rvalyi
Copy link
Member

rvalyi commented Feb 5, 2021

outra coisa, so um um .travis.yml de 14 linhas https://github.com/akretion/nfelib/blob/master_gen_v4_00/.travis.yml , a lib ja ta testada com Python 3.5, 3.5, 3.7 e 3.8 com o mesmo pytest que roda no seu Tox.

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants