Protege tus proyectos de Python Evita la invocación directa de setup.py para una máxima protección del código.

Protege tus proyectos de Python. Evita la invocación directa de setup.py para proteger al máximo el código.

Es hora de decir adiós a las complejidades de setup.py y abrazar el empaquetado eficiente de Python con interfaces de construcción.

En este artículo, exploraremos los desafíos enfrentados por distutils y setuptools, y por qué invocar directamente setup.py ya no es el mejor enfoque. Distutils y Setuptools fueron en su momento significativos, pero tuvieron limitaciones al usar setup.py directamente. Distutils carecía de características modernas, mientras que setuptools introdujo complejidades y desafíos de portabilidad.

Cambiando su enfoque, el equipo de setuptools está dejando de proporcionar una interfaz de línea de comandos y se centra en ser una biblioteca para crear paquetes. Este cambio no significa que setuptools esté siendo descontinuado, sino que se debe evitar la ejecución directa del archivo setup.py.

El uso de herramientas de gestión de dependencias como pip o Poetry se convierte en un elemento crucial aquí, automatizando el proceso de construcción e instalación de paquetes. Abrazar su simplicidad, portabilidad y beneficios de futuro es clave para el éxito en el empaquetado moderno de Python.

Tradicionalmente, setup.py servía como punto de entrada al mundo del empaquetado de Python. Los desarrolladores confiaban en él para definir los metadatos del proyecto, las dependencias y las instrucciones de instalación. La invocación del script era tan sencilla como ejecutar python setup.py install, y parecía el método por defecto para empaquetar proyectos de Python.

• Revelando el poder del ajuste de sesgo mejorando la precisión predictiva en conjuntos de datos desequilibrados
• Adobe Express mejora la experiencia del usuario con Firefly Generative AI
• Redes convolucionales de grafos Introducción a las GNN

Sin embargo, la historia no termina ahí. Los testimonios personales a menudo revelan las limitaciones y peculiaridades de depender únicamente de setup.py. Como muchos desarrolladores, me encontré enredado en una maraña de conflictos de dependencias confusos e incompatibilidades de versiones al trabajar en un proyecto que utilizaba distutils y setuptools. Era como perseguir sombras, ya que una actualización de una biblioteca desencadenaba una cascada de errores inesperados.

Imagina que estás construyendo un paquete llamado “my_package” con un módulo simple llamado “my_module.py”. En el pasado, tu proceso de empaquetado podría haber sido algo así:

# setup.pyfrom distutils.core import setup

setup(    name='my_package',    version='1.0',    py_modules=['my_module'],    # Otros metadatos...)

Inocente, ¿verdad? Pero a medida que tu proyecto se vuelve más complejo, distutils revela sus limitaciones, este enfoque carece de muchas características avanzadas como la gestión de dependencias y la instalación automática.

Setuptools irrumpió en escena prometiendo características avanzadas y gestión de dependencias. Setuptools es una mejora sobre distutils, pero incluso está siendo descontinuado a favor de herramientas de empaquetado más modernas.

Supongamos que tienes un proyecto más complejo que requiere dependencias externas y metadatos adicionales:

# setup.pyfrom setuptools import setup

setup(    name='my_package',    version='1.0',    packages=['my_package'],    install_requires=[        'requests',        'numpy',    ],    # Otros metadatos...)

Setuptools inicialmente mejoró el desarrollo de Python con características como la distribución simplificada de paquetes, la gestión de dependencias y las mejoras de metadatos. Ejecutar python setup.py sdist crearía una distribución de origen tanto para distutils como para setuptools. Sin embargo, a medida que Python evolucionaba, surgieron limitaciones:

1. Conflictos de instalación globales: Setuptools causaba conflictos al instalar diferentes versiones de dependencias globalmente, lo que provocaba problemas de compatibilidad entre proyectos.
2. Complejidad y mantenibilidad: A medida que los proyectos crecían, gestionar los archivos setup.py se volvía complejo, requiriendo actualizaciones en múltiples proyectos y ralentizando el desarrollo.
3. Aislamiento y reproducibilidad: Setuptools luchaba por aislar las dependencias del proyecto, lo que dificultaba la creación de entornos consistentes en diferentes sistemas.
4. Falta de estandarización: Setuptools carecía de una estructura de proyecto o formato de configuración estandarizado, lo que causaba fragmentación en la organización del proyecto.

Sin embargo, una desventaja notable de setuptools es su inconsistencia al manejar la resolución de dependencias en diferentes plataformas y entornos. Esta inconsistencia a menudo plantea desafíos al intentar instalar un paquete en diferentes sistemas. Para abordar estos problemas, un enfoque alternativo implica el uso de interfaces de construcción.

Los desafíos planteados por enfoques tradicionales como setuptools han llevado a la introducción de PEP 518 y PEP 517, junto con la adopción del archivo pyproject.toml. PEP 518 y PEP 517 trajeron un avance notable: la división entre la interfaz de construcción y el backend. Esto permite a los desarrolladores cambiar fácilmente las herramientas de construcción según sus necesidades. Por ejemplo, diferentes herramientas para desarrollo local, pruebas o construcción para producción.

En lugar de buscar a través de un archivo setup.py complicado, puedes gestionar la configuración, las dependencias y los ajustes de compilación de tu proyecto en un solo lugar centralizado, el archivo pyproject.toml. Este único archivo se convierte en tu centro de comando, facilitando la gestión de tu proyecto.

[tool.poetry]name = "mi_paquete"version = "1.0"[tool.poetry.dependencies]python = "^3.6"requests = "^2.25"numpy = "^1.20"[build-system]requires = ["poetry-core>=1.0.0"]build-backend = "poetry.core.masonry.api"

Aquí, la configuración está organizada de forma ordenada y expresiva. Las dependencias se definen con rangos de versión, lo que permite flexibilidad mientras se garantiza la compatibilidad. La sección [build-system] es donde ocurre la magia. La sección [tool.poetry] define los metadatos y las dependencias del proyecto, mientras que la sección [build-system] especifica el backend de compilación, que es responsable de ejecutar el proceso de compilación.

Cuando estés preparado para construir tu paquete, el comando ‘poetry build‘ es todo lo que se necesita.

El viaje de las herramientas de empaquetado de Python ha sido una aventura. En el pasado, distutils y setuptools eran los campeones, haciendo todo lo posible para satisfacer las necesidades de su época. Pero a medida que el mundo del desarrollo de software evolucionaba, se encontraron un poco fuera de su liga.

Poetry no solo se trata de simplificar la maraña de dependencias; es como fortificar el núcleo mismo de tu proyecto. Imagínalo como una capa adicional de resistencia que refuerza los cimientos de tu proyecto, haciéndolos más robustos y preparados para el futuro.

Así que recuerda, mientras distutils y setuptools fueron las estrellas de su época, el escenario ahora le pertenece a poetry y sus compañeros.

¡Gracias por leer! Espero que hayas encontrado útil esta publicación. Si deseas obtener más información, por favor consulta el artículo que sirvió como base para esta discusión. También puedes conectarte conmigo en LinkedIn o VoAGI para estar al día con mi último trabajo.

Hasta la próxima, Anushka!

We will continue to update Zepes; if you have any questions or suggestions, please contact us!