Mais uma sugestão para facilitar a manutenção/desenvolvimento do projeto no futuro (uma mudança mais assessória...).
- Seguir a pep 612 e adicionar metadados do projeto no
pyproject.toml. Basicamente todo projeto em python hoje em dia ja segue (alguns exemplos dentre os famosos numpy, httpx, black, django, flask, sqlalchemy...)
- Retirar a duplicação dos metadados do
setup.py e setup.cfg, ja que eles estarão no pyproject (não sei se é obrigatório... mas vai ficar mais facil de manter!)
- Retirar duplicação das bibliotecas dependentes do
./requirements. Elas ja estariam especificadas nos seus devidos grupos do pyproject.toml.
- Aproveitar que todos esses acima serão feitos e especificar o poetry como ferramenta única para gerenciamento dos metadados do projeto. Ele facilita muito a interação com o
pyproject.toml. De quebra ele ainda ajudará no build e publicação dos wheels.
- Adicionar o black como dependencia explícita de desenvolvimento de projeto. Hoje em dia o black é exigido no pre-commit mas não esta explicita a dependencia dele.
- Pequena mudança de estilo na estrutura modificando o nome da pasta de
src para o formato mais pythonico e direto de sidrapy. Esse racional é descrito de uma forma melhor do que eu conseguiria explicar nesse post. Os principais projetos python tb ja seguem esse padrão (de todos apresentados na pep 612, somente o flask e o black ainda não seguem... todos os outros ja estão assim)
Mais uma sugestão para facilitar a manutenção/desenvolvimento do projeto no futuro (uma mudança mais assessória...).
pyproject.toml. Basicamente todo projeto em python hoje em dia ja segue (alguns exemplos dentre os famosos numpy, httpx, black, django, flask, sqlalchemy...)setup.pyesetup.cfg, ja que eles estarão nopyproject(não sei se é obrigatório... mas vai ficar mais facil de manter!)./requirements. Elas ja estariam especificadas nos seus devidos grupos dopyproject.toml.pyproject.toml. De quebra ele ainda ajudará no build e publicação dos wheels.srcpara o formato mais pythonico e direto desidrapy. Esse racional é descrito de uma forma melhor do que eu conseguiria explicar nesse post. Os principais projetos python tb ja seguem esse padrão (de todos apresentados na pep 612, somente o flask e o black ainda não seguem... todos os outros ja estão assim)