🤱🏻 👵 🧘 Encontrando o Kit de Ferramentas Perfeito: Analisando Modelos de Projeto Python Populares 👩🏽‍⚖️ 👨🏾‍🤝‍👨🏼 🚧

O material, cuja tradução publicamos hoje, é dedicado à história sobre as ferramentas usadas para criar aplicativos Python. Ele foi desenvolvido para aqueles programadores que já deixaram a categoria de iniciantes, mas ainda não atingiram a categoria de desenvolvedores experientes em Python. Para quem está ansioso para começar a praticar, o autor sugere o uso do Flake8 , pytest e Sphinx em projetos existentes do Python . Ele também recomenda um pré-commit , Black e Pylint . Aqueles que planejam iniciar um novo projeto, ele aconselha a prestar atenção à Poesia e ao Dependabot .

Visão geral

Sempre foi difícil para mim formar uma opinião objetiva sobre as “melhores práticas” do desenvolvimento do Python. No mundo da tecnologia, algumas tendências populares estão constantemente surgindo, muitas vezes não existem por muito tempo. Isso complica a extração do "sinal útil" do ruído da informação.

As ferramentas mais recentes geralmente são boas, por assim dizer, no papel. Eles podem realmente ajudar o programador prático com alguma coisa? Ou sua aplicação apenas leva à introdução de algo novo no projeto, cuja eficiência deve ser mantida, que traz mais dificuldades do que benefícios?

Eu não tinha uma compreensão clara do que exatamente considerava as "melhores práticas" de desenvolvimento. Suponho que encontrei algo útil, baseado principalmente em evidências episódicas de "utilidade" e em menções ocasionais a isso em conversas. Nas últimas duas semanas, decidi colocar as coisas em ordem nesse assunto. Para fazer isso, comecei a analisar todos os modelos de projetos Python que consegui encontrar (estamos falando de modelos usados pelo utilitário de linha de comando cookiecutter para criar projetos Python com base neles).

Pareceu-me que era muito interessante aprender sobre quais ferramentas auxiliares os autores do modelo consideram dignas de colocar essas ferramentas em novos projetos Python criados com base nesses modelos.

Analisei e comparei os 18 projetos de modelos mais populares (de 76 a 6300 estrelas no GitHub), prestando atenção especial a que tipo de ferramentas auxiliares eles usam. Os resultados desta análise podem ser encontrados nesta tabela.

Abaixo, quero compartilhar as principais conclusões que tirei ao analisar modelos populares.

Padrões de fato

As ferramentas discutidas nesta seção estão incluídas em mais da metade dos modelos. Isso significa que eles são percebidos como padrão em um grande número de projetos Python reais.

▍Flake8

Estou usando o Flake8 há algum tempo , mas não sabia sobre a posição dominante no campo de fiapos que essa ferramenta ocupa. Eu pensei que ele existe em um tipo de competição, mas a grande maioria dos modelos de projetos o usa.

Sim, isso não é surpreendente. É difícil opor algo à conveniência de aprender toda a base de código do projeto em questão de segundos. Quem quiser usar desenvolvimentos de ponta pode recomendar um guia de estilo wemake-python-styleguide . Isso é algo como "Flake8 em esteróides". Essa ferramenta pode muito bem contribuir para a transferência para a categoria de outras ferramentas similares obsoletas (como Pylint).

YTeste de teste e cobertura.py

A grande maioria dos modelos usa pytest . Isso reduz o uso da estrutura de teste padrão mais unittest. Pytest parece ainda mais atraente quando combinado com tox . Foi exatamente o que foi feito em cerca de metade dos modelos. A cobertura do código com testes é mais frequentemente verificada usando o cover.py .

▍Esfinge

A maioria dos modelos usa o Sphinx para gerar documentação . Para minha surpresa, o MkDocs raramente é usado para esse fim.

Como resultado, podemos dizer que, se você não usa Flake8, pytest e Sphinx em seu projeto atual, considere apresentá-los.

Ferramentas promissoras

Nesta seção, coletei essas ferramentas e técnicas de trabalho, cuja utilização nos modelos sugeria algumas tendências. O ponto é que, embora tudo isso não apareça na maioria dos modelos de projeto, ele é encontrado em muitos modelos bastante recentes. Então - tudo isso vale a pena prestar atenção.

▍Pyproject.toml

O uso do arquivo é pyproject.tomlsugerido no PEP 518 . Este é um mecanismo moderno para especificar os requisitos de montagem do projeto. É usado na maioria dos modelos jovens.

▍Poesia

Embora o ecossistema Python não esteja indo bem em termos de uma boa ferramenta para gerenciar dependências, cautelosamente otimista de que Poesia pode ser o equivalente a npm do mundo JavaScript no mundo Python .

Os modelos de projeto mais jovens (mas, no entanto, populares) parecem concordar com essa ideia minha. É verdade que vale a pena dizer que, se alguém estiver trabalhando em algum tipo de biblioteca que ele pode planejar distribuir através do PyPI , ele ainda precisará usar o setuptools . (Note-se que após a publicação deste material fui informado de que isso, aparentemente, não é mais um problema).

Além disso, tenha cuidado se o seu projeto (o mesmo vale para dependências) depende do Conda. Nesse caso, o Poetry não combina com você, pois essa ferramenta, em sua forma atual, vincula o desenvolvedor ao pip e ao virtualenv .

▍Dependabot

O Dependabot verifica regularmente se há obsolescência nas dependências do projeto e tenta ajudar o desenvolvedor abrindo automaticamente o PR.

Pessoalmente, eu vi essa ferramenta mais frequentemente do que antes. Parece-me que é uma excelente ferramenta, cuja adição ao projeto afeta o projeto muito positivamente. O Dependabot ajuda a reduzir os riscos de segurança, pressionando os desenvolvedores a manter as dependências atualizadas.

Como resultado, aconselho a não perder de vista a poesia e o Dependabot. Considere introduzir essas ferramentas no seu próximo projeto.

Recomendações pessoais

A análise dos modelos de projeto me deu uma percepção um tanto ambivalente das ferramentas que listarei nesta seção. De qualquer forma, quero usar esta seção para falar sobre eles com base em minha própria experiência. Ao mesmo tempo, eles foram muito úteis para mim.

▍Pré-confirmar

Mesmo se você for extremamente disciplinado - não gaste sua energia executando ações simples de rotina, como código adicional executado pelo linter antes de enviar o código ao repositório. Tarefas semelhantes podem ser passadas para pré-confirmação . E é melhor gastar sua energia no TDD e no trabalho em equipe no código.

▍Pilint

Embora o Pylint seja criticado por ser lento, embora essa ferramenta seja criticada pelos recursos de suas configurações, posso dizer que me permitiu crescer acima de mim no campo da programação.

Ele me fornece instruções específicas sobre as partes do código que eu posso melhorar, me diz como fazer o código cumprir melhor as regras. Para uma ferramenta gratuita, isso por si só já é muito. Portanto, estou pronto para suportar os inconvenientes associados ao Pylint.

▍Preto

Preto na raiz do debate sobre onde colocar espaços no código. Isso protege nossas equipes de conversas vazias e de diferenças sem sentido nos arquivos causadas pelas diferentes configurações dos editores.

No meu caso, isso ilumina o que eu pessoalmente não gosto em Python (a necessidade de usar muitos espaços). Além disso, deve-se notar que o projeto Black em 2019 ingressou na Python Software Foundation, o que indica a seriedade e a qualidade desse projeto.

Como resultado, quero dizer que, se você ainda não usa o pré-commit, Black e Pylint - pense se essas ferramentas podem beneficiar sua equipe.

Subtotais

Doze dos dezoito modelos investigados foram criados usando a estrutura do cookiecutter . Alguns desses modelos em que essa estrutura não é usada têm qualidades interessantes.

Mas, considerando que o cookiecutter é a estrutura principal para a criação de modelos de projeto, aqueles que decidem usar um modelo que não utilizou um cookiecutter devem ter boas razões para isso. Essa decisão deve ser muito bem justificada.

Quem procura um modelo para seu projeto deve escolher um modelo que melhor se aproxime de sua própria visão das coisas. Se você, ao criar projetos de acordo com um determinado modelo, precisa constantemente reconfigurá-los da mesma maneira, pense em como bifurcar esse modelo e refiná-lo, inspirado nos exemplos de modelos da minha lista.

E se você é atraído pela aventura - crie seu próprio modelo a partir do zero. O Cookiecutter é um ótimo recurso do ecossistema Python, e o simples processo de criação de modelos Jinja permite que você faça algo rápido e fácil.

Bônus: Recomendações de modelo

▍Django

Juntamente com os modelos Django mais populares, considere usar o modelo wemake-django-template . Dá a impressão de um produto profundamente pensado.

Processing Processamento e análise de dados

Na maioria dos projetos destinados ao processamento e análise de dados, o modelo Cookiecutter Data Science é útil . No entanto, os cientistas de dados também devem olhar para o Kedro .

Este modelo estende o Cookiecutter Data Science com um mecanismo para criar pipelines padronizados de processamento de dados. Ele suporta carregar e salvar dados e modelos. É muito provável que esses recursos sejam capazes de encontrar aplicativos dignos em seu próximo projeto.

Aqui também gostaria de expressar minha gratidão aos criadores do modelo shablona por preparar documentação de alta qualidade. Pode ser útil para você, mesmo que você escolha outra coisa.

▍ Modelos de uso geral

Qual modelo de uso geral escolher de alguma forma depende do que exatamente você desenvolverá com base nesse modelo - uma biblioteca ou um aplicativo regular. Mas, escolhendo esse modelo, juntamente com os projetos mais populares desse tipo, eu olhava com muito cuidado o modelo Python de Jace .

Este não é um padrão bem conhecido, mas eu gosto do fato de que ele possui Poesia, Isort , Black, Pylint e Mypy .

O PyScaffold é um dos modelos mais populares não baseados em cortadores de carne . Possui muitas extensões (por exemplo, para Django e para projetos de ciência de dados ). Ele também baixa os números de versão do GitHub usando o setuptools-scm. Além disso, este é um dos poucos modelos que suportam o Conda.

Aqui estão alguns modelos que usam a tecnologia GitHub Actions:

O modelo do Cookiecutter do Python Best Practices , que, quero observar, possui a maioria das minhas ferramentas favoritas.
O modelo Blueprint / Boilerplate for Python Projects , que eu acho bastante interessante, como a oportunidade que eles oferecem para encontrar problemas de segurança comuns com o Bandit, parece promissor. Além disso, este modelo possui um recurso notável, que consiste no fato de que as configurações de todas as ferramentas são coletadas em um único arquivo setup.cfg.

E finalmente - eu recomendo dar uma olhada no modelo wemake-python-package . Eu acho que vale a pena fazer assim mesmo. Em particular - se você gosta do Django-template do mesmo desenvolvedor ou se usa o avançado wemake-python-styleguide em vez do puro Flake8.

Sumário

Depois que publiquei este artigo, escrevi sobre Guido van Rossum.

Talvez você, como eu, esteja interessado no comentário dele . Ele disse que eu esqueci o mypy e que é mais fácil trabalhar não com a Sphinx, mas com o Markdown. Em relação a Black, ele observou que essa ferramenta é superestimada e só pode se beneficiar se os membros da equipe discutirem muito sobre estilos. Segundo ele, quem usa o Flake8 não precisa do Pylint. Ele não tinha ouvido falar de poesia e dependabot. Além disso, ele aconselhou o uso de uma certa solução de IC, como o Travis-CI, para executar testes.

Queridos leitores! Quais modelos de projeto Python você usa?

Encontrando o Kit de Ferramentas Perfeito: Analisando Modelos de Projeto Python Populares