Encontrar el kit de herramientas perfecto: analizar plantillas de proyectos de Python populares

El material, cuya traducción publicamos hoy, está dedicado a la historia sobre las herramientas utilizadas para crear aplicaciones Python. Está diseñado para aquellos programadores que ya han abandonado la categoría de principiantes, pero aún no han alcanzado la categoría de desarrolladores experimentados de Python. Para aquellos que están ansiosos por comenzar a practicar, el autor sugiere usar Flake8 , pytest y Sphinx en proyectos existentes de Python . También recomienda un vistazo a pre-commit , Black y Pylint . Aquellos que planean comenzar un nuevo proyecto, aconseja prestar atención a Poesía y Dependabot .





Visión general


Siempre me ha resultado difícil formar una opinión objetiva sobre las "mejores prácticas" del desarrollo de Python. En el mundo de la tecnología, algunas tendencias populares surgen constantemente, a menudo no existen por mucho tiempo. Esto complica la extracción de la "señal útil" del ruido de la información.

Las herramientas más recientes a menudo solo son buenas, por así decirlo, en papel. ¿Pueden realmente ayudar al programador práctico con algo? ¿O su aplicación solo conduce a la introducción de algo nuevo en el proyecto, cuya eficiencia debe mantenerse, lo que conlleva más dificultades que beneficios?

No tenía una comprensión clara de lo que exactamente consideraba las "mejores prácticas" del desarrollo. Supongo que encontré algo útil, basado principalmente en evidencia episódica de "utilidad", y en la mención ocasional de esto en las conversaciones. En las últimas semanas, decidí poner las cosas en orden en este asunto. Para hacer esto, comencé a analizar todas las plantillas de proyectos de Python que pude encontrar (estamos hablando de plantillas utilizadas por la utilidad de línea de comandos de cookiecutter para crear proyectos de Python basados ​​en ellas).

Me pareció que era muy interesante descubrir qué tipo de herramientas auxiliares los autores de plantillas consideran dignas de incorporar estas herramientas en nuevos proyectos de Python creados a partir de estas plantillas.

Analicé y comparé los 18 proyectos de plantillas más populares (de 76 a 6300 estrellas en GitHub), prestando especial atención a qué tipo de herramientas auxiliares usan. Los resultados de este análisis se pueden encontrar en esta tabla.

A continuación quiero compartir las principales conclusiones que he hecho al analizar plantillas populares.

Estándares de facto


Las herramientas discutidas en esta sección están incluidas en más de la mitad de las plantillas. Esto significa que se perciben como estándar en una gran cantidad de proyectos reales de Python.

▍Flake8


He estado usando Flake8 durante bastante tiempo , pero no sabía sobre la posición dominante en el campo de la linting que ocupa esta herramienta. Pensé que existe en una especie de competencia, pero la gran mayoría de las plantillas de proyectos lo usan.

Sí, esto no es sorprendente. Es difícil oponerse a algo a la conveniencia de alinear toda la base de código del proyecto en cuestión de segundos. Aquellos que quieran utilizar desarrollos de vanguardia pueden recomendar un vistazo a wemake-python-styleguide . Esto es algo así como "Flake8 con esteroides". Esta herramienta puede contribuir a la transferencia a la categoría de otras herramientas similares obsoletas (como Pylint).

▍Pytest y cobertura.py


La gran mayoría de las plantillas usan pytest . Esto reduce el uso del marco de prueba estándar unittest. Pytest se ve aún más atractivo cuando se combina con tox . Eso es exactamente lo que se hizo en aproximadamente la mitad de las plantillas. La cobertura del código con las pruebas se verifica con mayor frecuencia usando coverage.py .

▍Esfinge


La mayoría de las plantillas usan Sphinx para generar documentación . Para mi sorpresa, MkDocs rara vez se usa para este propósito.

Como resultado, podemos decir que si no usa Flake8, pytest y Sphinx en su proyecto actual, entonces debería considerar introducirlos.

Herramientas prometedoras


En esta sección, he recopilado esas herramientas y técnicas de trabajo, cuyo uso en las plantillas sugirió algunas tendencias. El punto es que, aunque todo esto no aparece en la mayoría de las plantillas de proyecto, se encuentra en muchas plantillas bastante recientes. Entonces, vale la pena prestar atención a todo esto.

▍Pyproject.toml


El uso de archivos se pyproject.tomlsugiere en PEP 518 . Este es un mecanismo moderno para especificar los requisitos de ensamblaje del proyecto. Se usa en la mayoría de las plantillas bastante jóvenes.

▍Poesía


Aunque el ecosistema de Python no funciona bien en términos de una buena herramienta para administrar dependencias, soy cautelosamente optimista de que Poetry podría ser el equivalente de npm del mundo de JavaScript en el mundo de Python .

Las plantillas de proyecto más jóvenes (pero, sin embargo, populares) parecen estar de acuerdo con esta idea mía. Es cierto que vale la pena decir que si alguien está trabajando en algún tipo de biblioteca que puede planear distribuir a través de PyPI , entonces todavía tiene que usar herramientas de configuración . (Cabe señalar que después de la publicación de este material me informaron que, aparentemente, esto ya no es un problema).

Además, tenga cuidado si su proyecto (lo mismo ocurre con las dependencias) depende de Conda. En este caso, Poetry no le conviene, ya que esta herramienta, en su forma actual, vincula al desarrollador a pip y virtualenv .

▍Dependabot


Dependabot verifica regularmente las dependencias del proyecto en busca de obsolescencia e intenta ayudar al desarrollador abriendo PR automáticamente.

Personalmente, recientemente he visto esta herramienta con más frecuencia que antes. Me parece que es una herramienta excelente, cuya incorporación al proyecto afecta al proyecto de manera muy positiva. Dependabot ayuda a reducir los riesgos de seguridad al presionar a los desarrolladores a mantener las dependencias actualizadas.

Como resultado, te aconsejo que no pierdas de vista Poesía y Dependabot. Considere introducir estas herramientas en su próximo proyecto.

Recomendaciones personales


El análisis de las plantillas de proyecto me dio una percepción algo ambivalente de las herramientas que enumeraré en esta sección. En cualquier caso, quiero usar esta sección para hablar sobre ellos según mi propia experiencia. Hubo un tiempo en que me fueron muy útiles.

▍Pre-commit


Incluso si es extremadamente disciplinado, no desperdicie su energía en realizar acciones de rutina simples, como ejecutar código adicional a través de la interfaz antes de enviar el código al repositorio. Se pueden pasar tareas similares a Pre-commit . Y es mejor gastar su energía en TDD y en el trabajo en equipo en código.

▍Pylint


Aunque Pylint es criticado por ser lento, aunque esta herramienta es criticada por las características de su configuración, puedo decir que me permitió crecer por encima de mí mismo en el campo de la programación.

Me da instrucciones específicas sobre aquellas partes del código que puedo mejorar, me dice cómo hacer que el código cumpla mejor con las reglas. Para una herramienta gratuita, esto solo ya es mucho. Por lo tanto, estoy listo para soportar los inconvenientes asociados con Pylint.

▍Negro


Negro en la raíz del debate sobre dónde poner espacios en el código. Esto protege a nuestros equipos de conversaciones vacías y de diferencias sin sentido en los archivos causadas por diferentes configuraciones de editores.

En mi caso, esto ilumina lo que personalmente no me gusta en Python (la necesidad de usar muchos espacios). Además, debe tenerse en cuenta que el proyecto Black en 2019 se unió a Python Software Foundation, lo que indica la seriedad y calidad de este proyecto.

Como resultado, quiero decir que si todavía no usa precompromiso, Black y Pylint, piense si estas herramientas pueden beneficiar a su equipo.

Subtotales


Doce de las dieciocho plantillas investigadas se crearon utilizando el marco de corte de cookies . Algunas de esas plantillas donde no se usa este marco tienen cualidades interesantes.

Pero dado el hecho de que cookiecutter es el marco principal para crear plantillas de proyecto, aquellos que decidan usar una plantilla que no haya utilizado un cookiecutter deberían tener muy buenas razones para ello. Tal decisión debe estar muy bien justificada.

Aquellos que buscan una plantilla para su proyecto deben elegir una plantilla que coincida más con su propia visión de las cosas. Si, al crear proyectos de acuerdo con una plantilla determinada, tiene que reconfigurarlos constantemente de la misma manera, piense en hacer una bifurcación de dicha plantilla y finalizarla, inspirada en ejemplos de plantillas de mi lista.

Y si te atrae la aventura, crea tu propia plantilla desde cero. Cookiecutter es una gran característica del ecosistema Python, y el simple proceso de crear plantillas Jinja le permite hacer algo propio de manera rápida y fácil.

Bonus: Recomendaciones de plantillas


JanDjango


Junto con las plantillas de Django más populares, considere usar wemake-django-template . Da la impresión de un producto profundamente pensado.

▍ Procesamiento y análisis de datos


En la mayoría de los proyectos destinados a procesar y analizar datos, la plantilla de Ciencia de datos de Cookiecutter es útil . Sin embargo, los científicos de datos también deberían mirar a Kedro .

Esta plantilla amplía la Ciencia de datos de Cookiecutter con un mecanismo para crear canales de procesamiento de datos estandarizados. Admite cargar y guardar datos y modelos. Es muy probable que estas características puedan encontrar aplicaciones valiosas en su próximo proyecto.

Aquí también me gustaría expresar mi gratitud a los creadores de la plantilla shablona por preparar documentación de muy alta calidad. Puede ser útil incluso si termina eligiendo otra cosa.

▍ Plantillas de uso general


La plantilla de propósito general que elija de alguna manera depende de lo que va a desarrollar exactamente en función de esta plantilla: una biblioteca o una aplicación normal. Pero, al elegir dicha plantilla, junto con los proyectos más populares de este tipo, miraría con mucho cuidado la Plantilla Python de Jace .

Este no es un patrón bien conocido, pero me gusta el hecho de que tiene Poesía, isort , negro, pylint y mypy .

PyScaffold es una de las plantillas más populares que no utilizan cookies. Tiene muchas extensiones (por ejemplo, para Django y para proyectos de Data Science ). También descarga números de versión de GitHub usando setuptools-scm. Además, esta es una de las pocas plantillas que admiten Conda.

Aquí hay un par de plantillas que usan la tecnología GitHub Actions:

  1. La plantilla Python Best Practices Cookiecutter , que, quiero señalar, tiene la mayoría de mis herramientas favoritas.
  2. La plantilla Blueprint / Boilerplate For Python Projects , que me parece bastante interesante, ya que la oportunidad que les brinda para encontrar problemas de seguridad comunes con Bandit, parece prometedora. Además, esta plantilla tiene una característica notable, que consiste en el hecho de que la configuración de todas las herramientas se recopila en un solo archivo setup.cfg.

Y finalmente, recomiendo echar un vistazo a la plantilla wemake-python-package . Creo que vale la pena hacerlo de todos modos. En particular, si le gusta la plantilla Django del mismo desarrollador, o si va a usar la guía avanzada de estilo wemake-python en lugar de Flake8 puro.

Resumen


Después de publicar este artículo, le escribí a Guido van Rossum al respecto.

Quizás usted, como yo, esté interesado en su comentario . Dijo que me olvidé de mypy y que es más fácil trabajar no con Sphinx, sino con Markdown. Con respecto a Black, señaló que esta herramienta está sobrevalorada y solo puede beneficiarse si los miembros del equipo discuten mucho sobre los estilos. Según él, aquellos que usan Flake8 no necesitan Pylint. No había oído hablar de Poesía y Dependabot. Además, aconsejó usar una determinada solución de CI, como Travis-CI, para ejecutar pruebas.

¡Queridos lectores! ¿Qué plantillas de proyecto de Python utilizas?


All Articles