Tecnologia / Artigos / Quick articles /
pip requirements files bem escritos

Cléber

* Date: 2018-10-21 16:41:47 * Modified: 2018-11-30 16:12:23 Recentemente me perguntaram, baseado em um item que citei no artigo “Github como currículo e visão geral sobre processos seletivos”[1], o que seria um “*requirements file bem escrito*”. E como a resposta pode interessar mais gente, resolvi responder em forma de um artigo “quick”. [1] https://medium.com/clebertech/github-como-curr%C3%ADculo-e-vis%C3%A3o-geral-sobre-processos-seletivos-37a2ed3e1f09 ## 1- Não é mero fruto de um “pip freeze” Um arquivo de requirements bom não deve incluir os “sub-requirements” dos pacotes que realmente importam. Se o seu projeto depende do pacote “A”, e o pacote “A”, por sua vez, depende de “b”, “c”, “d” e “e”, a única entrada que deve constar no seu requirements file é “A”. ## 2- Todos os pacotes estão pinados Ou então você estaria confiando a um terceiro que você provavelmente nem conhece a segurança e estabilidade do seu projeto inteiro. Além de ter testes automatizados que, na prática, não servem para garantir nada. ## 3- Ordenado alfabeticamente Isso é uma regra um pouco mais frouxa, porque há certos casos em que eu organizo os pacotes de maneira semântica dentro do requirements file. Mas, mesmo nesses casos em que o arquivo fica dividido em alguns “grupos”, dentro de cada grupo é sempre bom ordenar os pacotes por nome, em ordem alfabética. Algumas pessoas não diferenciam letras maiúsculas de minúsculas, o que é okay, **contanto que mantenha-se um padrão coerente dentro do projeto**. ## 4- Produção e testes separados Nada é mais irritante do que estar-se instalando um pacote e perceber que a tox foi instalada também. No seu projeto. Que nem usa tox. Eu costumo, para resolver essa questão, criar um diretório chamado “requirements” e, dentro dele, ter os arquivos “production.txt” e “tests.txt”. E, na raiz do projeto, meu “requirements.txt” contém somente uma entrada: -r requirements/production.txt # Resumo Talvez o que sumarize bem a definição de um arquivo de requirements bem escrito seja “feito com atenção”, e não como se fosse uma mera obrigação, algo que pode ser feito de qualquer jeito.

Curti

48 visitantes curtiram esse Item.

Anterior: Artigos / O Guia Definitivo para construção de APIs REST | Próximo: Por que eu não curto “pipfiles”