Inclusão do arquivo requirements.txt

[mbcosta]

Ola @aricaldeira eu inclui o arquivo requirements.txt para indicar as dependencias de bibliotecas python do PySPED.

[mileo]

@mbcosta vc poderia tb refatorar o trecho https://github.com/aricaldeira/PySPED/blob/master/setup.py#L50 para que o arquivo requirements.txt seja carregado para listar as dependencias do setup.py ?

E evitar termos dois locais que referenciam as dependências?

[alanjds]

Gente, acho que tem alguma confusão acontecendo por aqui, na minha opinião.

O setup.py deveria descrever as dependências mínimas pro pacote ser instalado. O requirements.txt não é um padrão Python, mas um padrão "de fato", descrevendo as dependências recomendadas de um projeto.

Se eu der clone em um repo, eu espero que tenha um requirements.txt com versões "frozen" pra eu instalar e rodar os testes e ele funcionar, mas também espero que tenha um setup.py e que esse setup.py seja mais "aberto" nas versões.

Quando você inclui uma biblioteca (como o PySPED) em um outro projeto (como qualquer "meuerp") este vai garantir que, ao instalar o PySPED, tudo que estiver listado no setup.py vai ser instalado antes dele. O requirements.txt não faz isso.

Geralmente o setup.py têm as dependências mínimas, aceitando versões posteriores. E o requirements.txt têm versões "congeladas" testadas entre si.

Assim, eu sugiro que o PR inclua no requirements.txt os números completos das versões, e copie sim manualmente os números mínimos dentro do setup.py

Espero ter ajudado mais que atrapalhado. See ya.

[romaia]

Uma alternativa a ter duas listas de dependências separadas, é fazer o setup.py ler o requirements.txt. Algo do tipo:

with open('requirements.txt') as f:
    install_requires = [l.strip() for l in f.readlines() if
                        l.strip() and not l.startswith('#')]

setup(..., install_requires=install_requires,...)

[mileo]

Alan concordo contigo, mas sei que o pysped não é um pacote simples e as dependências como o Geraldo por exemplo se buscadas do ligar errado podem prejudicar quem está tentando usar pela primeira vez.

Se forma que eu mantenho minha opinião para este caso, vocês podem ver um exemplo de implementação no link:

https://github.com/kmee/satcfe/blob/master/setup.py

Abraços

Sent from Nine

---

De: Alan Justino da Silva notifications@github.com Enviado: 19/04/2017 3:01 PM Para: aricaldeira/PySPED Cc: Luis Felipe Miléo; Comment Assunto Re: [aricaldeira/PySPED] Inclusão do arquivo requirements.txt (#58)

Gente, acho que tem alguma confusão acontecendo por aqui, na minha opinião.

O setup.py deveria descrever as dependências mínimas pro pacote ser instalado. O requirements.txt não é um padrão Python, mas um padrão "de fato", descrevendo as dependências recomendadas de um projeto.

Se eu der clone em um repo, eu espero que tenha um requirements.txt com versões "frozen" pra eu instalar e rodar os testes e ele funcionar, mas também espero que tenha um setup.py e que esse setup.py seja mais "aberto" nas versões.

Quando você inclui uma biblioteca (como o PySPED) em um outro projeto (como qualquer "meuerp") este vai garantir que, ao instalar o PySPED, tudo que estiver listado no setup.py vai ser instalado antes dele. O requirements.txt não faz isso.

Geralmente o setup.py têm as dependências mínimas, aceitando versões posteriores. E o requirements.txt têm versões "congeladas" testadas entre si.

Assim, eu sugiro que o PR inclua no requirements.txt os números completos das versões, e copie sim manualmente os números mínimos dentro do setup.py

Espero ter ajudado mais que atrapalhado. See ya.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/aricaldeira/PySPED/pull/58#issuecomment-295368818

[rvalyi]

Ola galera. Confesso que nao domino o Python tanto assim. Mas na questao da logica, o Ruby tem um pouco a mesma coisa: assim como o @alanjds falou, temos o Gemfile/ Gemfile.lock que tem versoes congeladas testadas no projeto (como no requirements.txt) e temos o .gemspec no qual tem as versoes de forma mais folgadas no objetivo da inclusao como lib num projeto maior sem criar conflitos.

No Ruby, a gente tem a instrucao 'gemspec' no Gemfile que significa que vai importar as dependencias do arquivo .gemspec antes talvez que seja completado de forma mais forte no arquivo Gemfile ou mais congelado no arquivo Gemfile.lock. Um examplo com o projeto Devise: https://github.com/plataformatec/devise/blob/master/Gemfile#L3 https://github.com/plataformatec/devise/blob/master/devise.gemspec https://github.com/plataformatec/devise/blob/master/Gemfile.lock

O sistema de pacote do Ruby e reputado bem feito (ao contrario do que aconteceu por anos no Python pelo menos). E ate onde eu sei os responsaveis do Python estao tentando copiar esse sistema e o Bundler (nao e para fazer flame war, basta ler as declaracoes do proprio Tarek Ziade sobre o assunto por examplo, sendo que ele o proprio cara que trabalhou no sistema de pacotes do Python na Mozilla).

Sendo assim, @mileo tou achando estranho o que vcs fizeram no https://github.com/kmee/satcfe/blob/master/setup.py Na minha opinao deveria ser o contrario: deveria ser o requirements.txt que deveria importar as versoes mais abertas do arquivo setup,py. Se é o arquivo setup.py que importa as coisas do requirements.txt ai vai contra logica que o @alanjds descreveu: pois sera o setup.py que sera super rigido, potencializando riscos de conflitos ao incluir a lib pysped num projeto maior. E se for para evitar isso e que botamos o requirements.txt mais folgado, ai ele simplesmente serve para nada. Ou seja, me parece ate pior do que de manter o requirements.txt manualmente.

Agora ignoro se o Python permite ou nao de importar as dependencias do setup.py no requirements.txt. @alanjds vc sabe? @romaia o que acha?

[mileo]

@rvalyi o exemplo que eu dei foi de um fork.

Mas temos outros exemplos aqui:

https://github.com/OCA/maintainer-tools https://github.com/OCA/pylint-odoo

Confesso que não nunca li a documentação relacionada a essa sopa de setup.py / setup.cfg e requirements.txt mas notei uma evolução da forma que estes arquivos são definidos. Vou pesquisar a respeito e volto a comentar.

Enquanto isso convido o @leorochael a participar da discussão.

Abraços

[alanjds]

@rvalyi: É complicado. Realmente no Python 3 estão mudando algumas coisas pra ter um Gemfile-like, mas é um ponto controverso. A "disgraça" no nosso caso é que o setup.py usa os nomes/versões de pacote no "registro" interno do Python da máquina. Quando vc instala o Geraldo via github/aricaldeira, fica registrado que "o geraldo tá instalado, versão X.Y", não que veio do github.

Até teria como informar pro setup.py que "se não tiver já instalado, baixa do github", mas se já tiver a versão PyPI ele vai se contentar com o que estiver já.

@mileo: Eu já vi projetos fazendo isso de requirements.txt sendo "importado" no setup.py, só que não funciona pra coisas fora do PyPI, como "geraldo do github/aricaldeira". Se vier tudo do PyPI sempre, então tudo bem.

@rvalyi: ...mas nunca vi o contrário: setup.py criando o requirements.txt. Até porque se não tiver um requirements.txt na pasta eu vou direto no setup.py pra olhar as dependências.

Assim, o requirements.txt acaba sendo um apoio pro desenvolvimento, não uma ferramenta do sistema de pacotes.

[mileo]

Eu achei este artigo com algumas considerações interessantes relacionadas aos comentários do @alanjds e do @rvalyi. Ele foi baseado em um outro artigo que retrata o que ocorre no ruby.

https://caremad.io/posts/2013/07/setup-vs-requirement/

Outra coisa que não estamos nem considerando é o por que o as correções no geraldo não foram submetidas ao projeto?

[rvalyi]

@mileo so para accrescentar nesse off topic do Geraldo: me parece que o py3o por examplo e um projeto muito mais vivo do que o geraldo. Vi que recentemente tem coisas do PySPED que passam a usar py3o. Sera se nao deveria ser migrado para matar o uso do Geraldo de vez no PySPED? Lembrando na v11, o Odoo vem compativel com Python 3, Talvez obrigatorio na v12, ao meu ver carregar esse tipo de dependencia vai em lugar nenhum...

[leorochael]

Minha posição é a do artigo que o @mileo citou, e que concorda com o que @rvalyi e com o que @alanjds falaram:

• as dependências, sem restrições (ou apenas com restrições to tipo >=, ou no máximo <= para casos conhecidos de incompatibilidade com versões superiores), devem estar na chave install_requires do setup.py, enquanto o requirements.txt deve conter versões exatas que serão testadas automaticamente.

Neste PR, a informação que está no requirements.txt, sem as versões, seria a informação que deveria estar no install_requires do setup().

Exceto que, atualmente, o setup() tem uma chave requires com uma informação mais específica (indicando versões mínimas dos pacotes) que o requires.txt.

Só que essa chave parece estar com a sintaxe incorreta (i.e. lxml(>=3.7.3) ao invés de lxml>=3.7.3).

Então, ao invés de adicionar o requirements.txt sem especificação como nesse PR, o que eu sugiro é:

• Renomear requires para install_requires
• Harmonizar a informação com o que está no requirements.txt deste PR, adicionando versões mínimas e removendo pacotes que não são mais dependências.
• Colocar versões específicas (com ==) no requirements.txt demonstrando versões que garantidamente funcionam.

Para manter o requirements.txt em dia, atualizando-o para versões mais novas, recomendo utilizar pip-tools.

[leorochael]

Ah, se formos utilizar pip-tool, aí sim eu acho que pode valer a pena alimentar o install_requires lendo o arquivo requirements.in (mas não o requirements.txt que deve sempre ter versões exatas).