Tecnologia / Artigos / Quick articles /
Por que eu não curto “pipfiles”

Cléber

* Date: 2018-10-21 17:37:09 * Modified: 2018-11-30 16:12:23 ## O que é https://github.com/pypa/pipfile ```ini [[source]] url = 'https://pypi.python.org/simple' verify_ssl = true name = 'pypi' [requires] python_version = '2.7' [packages] requests = { extras = ['socks'] } records = 'ᐳ0.5.0' django = { git = 'https://github.com/django/django.git', ref = '1.11.4', editable = true } "e682b37" = {file = "https://github.com/divio/django-cms/archive/release/3.4.x.zip"} "e1839a8" = {path = ".", editable = true} pywinusb = { version = "*", os_name = "=='nt'", index="pypi"} [dev-packages] nose = '*' unittest2 = {version = "ᐳ=1.0,ᐸ3.0", markers="python_version ᐸ '2.7.9' or (python_version ᐳ= '3.0' and python_version ᐸ '3.4')"} ``` ## Sobre a minha posição Não estou aqui dizendo que a ideia é um erro e que o projeto deve ser abortado. Só acontece que a coisa toda não me apetece por uma série de motivos e eu gostaria de ter um link pronto para responder a quem me pergunta a respeito desse assunto. Se você gosta da ideia dos pipfiles, por favor, não se sinta ofendido. Você pode, inclusive, fazer comentários saudáveis que me ajudem a enxergar melhor algo que eu tenha deixado passar, por exemplo. Ademais, esse é um artigo “quick”: eu propositadamente não vou gastar o dia todo escrevendo-o, revisando-o e polindo-o o máximo possível. A ideia é ser um tipo de meio-termo entre uma postagem no Facebook e um artigo “de verdade”. Então algumas coisas podem acabar saindo mais grosseiras do que o usual. Isso é coisa típica da palavra escrita: não tenho um rosto para demonstrar minha emoção ou mãos para gesticular, então uma coisa ou outra pode ter aparência de algo que não é. ## Por que isso não me apetece ### 1- Que diacho de formato é esse? Essa é minha reclamação mais branda, porque esse TOML tem algumas coisinhas até legais. https://github.com/toml-lang/toml Entretanto, acho um contrassenso passar por cima de formatos mais consolidados, como YAML, ou, ainda mais importante, com boas ferramentas de manipulação via linha de comando, como JSON. Eu odeio configurações em JSON, mas pelo menos eu posso usar jq e jo para manipular… (Sim, deve haver alguma ferramenta que manipule TOML bem direitinho, mas é yet another para se aprender. (E as que eu vi, até agora, são todas baseadas em conversão para ainda outro formato antes de se poder manipular…)) #### 1.2- E o formato do requirements.txt hoje já é ok E até mesmo mudar, eventualmente, alguma versão dentro do arquivo é razoavelmente tranquilo com nossos velhos amigos grep e sed (ou gawk , se preferir). ### 2- Como eu vou manipular um arquivo desses via linha de comando? É comum que em certos ambientes seja necessário manipular requirements files antes, por exemplo, de um deploy. Que o diga quem precisa lidar com integrações “complicadas” como GDAL ou mesmo algumas bibliotecas que dependem do Cython. Hoje eu tenho, em produção, uma meia dúzia de situações nas quais me é muito mais vantagem criar um “arquivão” de requirements e mandar o pip instalar as coisas baseado nele. Mas com esse formato de pipfile, como faz? E mesmo que haja uma ferramenta estilo jq , ainda não é, absolutamente, a mesma coisa que usar o bom e velho ᐳᐳ do shell… ### 3- Qual é o problema de múltiplos “requirements files”? Eu nunca vi problema. Você cria um diretório chamado requirements e joga lá dentro o que quiser: production.txt , tests.txt , development.txt , paas.txt , etc. E tem vantagens: se passar algum problema de formatação em um arquivo, não chega a afetar os outros (especialmente, por exemplo, o development.txt , que é mexido com mais liberdade e não é referenciado por nenhum outro, em geral). ### 4- Lockfile é coisa de Rubysta Haha! Sorry, guys. Mas eu nunca achei sábio haver um “requirements.lock”. Eu acredito que a atitude certa com relação ao requirements.txt é justamente entender a importância de mantê-lo correto e de se entender completamente o que ele está fazendo. Na presença de um lockfile, o desenvolvedor tende a não “pinnar” as versões no arquivo “unlocked”, o que acaba tornando a atualização das bibliotecas uma constante, o que nem sempre é necessário, tampouco desejado. Pense no caso do novato que fez o git clone agora e, ao tentar rodas os testes, vê N erros pipocando na tela porque naquelas versões específicas das bibliotecas o projeto não funciona direito. “Ah, mas o certo é ele instalar justamente do lockfile”, você dirá. Ao que eu respondo: ok, que funciona com o lockfile os testes automatizados já comprovam. Mas e depois? Em que momento ele pode se ver livre do “lock”? Ele vai “despinnar” uma a uma das dependências do projeto? Copiando o lockfile no lugar do pipfile original e sumindo com os locks um a um? É válido sobrescrever o arquivo escrito pelos desenvolvedores com um escrito “pela máquina”? Eu só vejo complicações desnecessárias no uso de lockfiles, especialmente para trabalho em equipe. Não quer ter dor de cabeça? 1. Sempre tenha requirements files devidamente pinnados. 1. Atualize as bibliotecas (manualmente), mas considere isso uma alteração de código como qualquer outra. ### 5- Só default e development? O pipfile só suporta esses dois “ambientes”. Na Olist usávamos um arquivo requirements-paas.txt para indicar os requisitos para que cada microsserviço rodasse onde quer que estivesse hospedado. Porque, afinal, o gunicorn não é um requisito do projeto, por exemplo. Mas e agora? Usando um arquivo separado, eu configuro isso devidamente no meu sistema de deploy. Se alguém descobre que “precisa” de uma feature do uwsgi e prefere usá-lo ao invés do gunicorn , okay, da parte do sistema de deploy não muda-se nada. Mas com o pipfile, como faz? # Resumo Eu posso estar bem errado e daqui a alguns anos pode ser que eu escreva um artigo dizendo que pipfiles são uns lindos. Mas nesse momento eu não consigo vê-los com bons olhos…

Curti

55 visitantes curtiram esse Item.

Anterior: pip requirements files bem escritos | Próximo: Artigos / XFCE: quase como o Lada