MetsuOS

Construyendo la plena inclusión a través del videojuego

Cómo Poetry implementa los estándares PEP 517, 518, 621 y 660 🟡③

Cómo Poetry implementa los estándares PEP 517, 518, 621 y 660

Curso sobre desarrollo de un gestor de paquetes python que use poetry como backend 🟡③

Poetry no solo actúa como gestor de dependencias, sino también como backend de construcción que se alinea con los estándares modernos del ecosistema Python. Estos estándares, definidos en las PEPs (Python Enhancement Proposals) 517, 518, 621 y 660, permiten builds reproducibles, configuraciones declarativas y flujos de desarrollo más fluidos.

En esta lección, desglosamos de manera clara y práctica cómo Poetry los pone en marcha, con ejemplos reales que puedes probar en tu propio proyecto. El enfoque del curso, resalta cómo estos PEPs convierten a Poetry en un aliado ideal para extensiones como MetsuDepManager, donde la auditoría y la reproducibilidad son clave.

PEP 517: Un Formato de Empaquetado Independiente del Sistema de Construcción

El PEP 517 marca un antes y un después al separar el "frontend" (como pip) del "backend" de construcción, eliminando la dependencia de archivos como setup.py. Poetry lo implementa a través de poetry-core, un módulo ligero que sirve como backend conforme a este estándar. Esto significa que puedes construir tu proyecto con herramientas externas sin instalar Poetry al completo; basta con poetry-core para generar distribuciones fuente (sdist) o wheels.

En la práctica, Poetry configura la tabla [build-system] en pyproject.toml para invocar hooks como build_wheel o get_requires_for_build_sdist. Esto acelera los builds en entornos de CI/CD y asegura independencia. Por ejemplo, en el curso, al invocar estos hooks vía subprocess o la API de Poetry (Lección 1.6), se logra una integración perfecta para MetsuDepManager, resolviendo problemas de reproducibilidad en setups aislados.

Aquí un ejemplo básico de pyproject.toml generado con poetry init:

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Con esto, un simple pip install . construye el paquete sin más complicaciones.

PEP 518: Especificación de Requisitos Mínimos del Sistema de Construcción

Este PEP resuelve el clásico "catch-22" de los builds: ¿cómo instalar dependencias de construcción si el build las necesita? Poetry lo maneja de forma nativa en [build-system], instalando automáticamente las dependencias listadas en requires en un entorno aislado antes de proceder.

Al ejecutar poetry install o un build, Poetry resuelve e instala temporalmente paquetes como setuptools o wheel, garantizando consistencia incluso con extensiones en C. En el contexto del curso (Módulo 3.2), esto es esencial para configurar MetsuDepManager sin conflictos globales, permitiendo envolver Poetry sin reinstalar nada innecesario.

Ejemplo extendido:

[build-system]
requires = ["poetry-core>=1.0.0", "setuptools>=45"]
build-backend = "poetry.core.masonry.api"

Poetry valida esta sección al vuelo, usando su resolvedor para detectar incompatibilidades tempranamente.

PEP 621: Almacenamiento de Metadatos del Proyecto en pyproject.toml

El PEP 621 estandariza cómo guardar metadatos como nombre, versión o autores en pyproject.toml, fomentando una configuración única y compatible. Poetry lo soporta desde la versión 1.2 y, en su madura 2.0 (lanzada en 2025), migra completamente a la tabla [project], aunque mantiene [tool.poetry] para funciones específicas como grupos de dependencias.

Esto permite declarar dependencias runtime en [project.dependencies] y exportar a requirements.txt con poetry export. En el curso (Lecciones 1.3 y 1.4), se usa para reemplazar setup.py en MetsuDepManager, mejorando la interoperabilidad con pip y Twine.

Ejemplo para un proyecto ético:

[project]
name = "metsudepmanager"
version = "0.1.0"
description = "Gestor ético de dependencias usando Poetry"
authors = [{name = "Raul Carrillo aka Metsuke", email = "metsuke@gmail.com"}]
dependencies = [
    "poetry-core>=1.0.0",
    "typer>=0.9.0",
    "rich>=13.0.0"
]
readme = "README.md"
requires-python = ">=3.11"
license = "GPL-3.0-or-later"
classifiers = [
    "License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)"
]

La licencia es GPL v3 según lo argumentado en ¿Qué licencia debe tener MetsuDepManager? 🟡③, decisión tomada a 8 de Diciembre de 2025.

Para extras, recurre a [dependency-groups] (PEP 735) o grupos de Poetry.

PEP 660: Instalaciones Editables (Modo de Desarrollo)

Este PEP extiende los anteriores para instalaciones editables, enlazando el código fuente directamente sin copias, ideal para iterar durante el desarrollo. Poetry lo habilita por defecto con poetry install, que enlaza el proyecto actual en modo editable vía poetry-core.

Soporta pip install -e . desde la 1.2, usando symlinks o paths directos para cambios en vivo. En el curso (Módulo 1.3 y workflows de desarrollo), esto acelera la iteración en MetsuDepManager sin rebuilds constantes, integrándose con poetry.lock para audits en installs editables.

Ejemplo de comando:

poetry install  # Instala dependencias + proyecto en editable (PEP 660)
# O con pip:
pip install -e .  # Backend de poetry-core maneja lo editable

Integración en el Curso y Beneficios Prácticos

El curso de MetsuKe posiciona estos PEPs como el núcleo de MetsuDepManager: un wrapper que invoca Poetry vía API o subprocess (Lección 1.6) para builds auditables y éticos. Los beneficios son claros: builds rápidos y reproducibles, compatibilidad total con pip/Twine y menos fricciones en el packaging. En 2025, con Poetry 2.0, pyproject.toml se consolida como la fuente única de verdad, alineándose con el ecosistema Python. Si estás desarrollando paquetes, empieza con poetry init y explora estos estándares; verás cómo simplifican todo.

Referencias Bibliográficas de Apoyo

  1. PEP 517 – A build-system independent format for source trees 🟡③🌐 .- Propuesta oficial que define el formato independiente para frontends y backends de construcción, implementado por Poetry vía poetry-core para builds reproducibles.
  2. PEP 518 – Specifying Minimum Build Dependencies in pyproject.toml 🟡③🌐 .- Documento que estandariza la declaración de dependencias de build en pyproject.toml, adoptado por Poetry para entornos aislados.
  3. PEP 621 – Storing project metadata in pyproject.toml 🟡③🌐 .- Especificación para metadatos en pyproject.toml, soportada por Poetry desde v1.2 y fully integrada en v2.0 para configuraciones declarativas.
  4. PEP 660 – Editable installs for pyproject.toml based builds 🟡③🌐 .- Extensión para instalaciones editables, habilitada en Poetry con poetry install para desarrollo ágil.
  5. Documentación oficial de Poetry: pyproject.toml 🟡③🌐 .- Guía detallada sobre la implementación de PEPs en Poetry, con ejemplos de [build-system] y [project].
  6. The Basics of Python Packaging in Early 2023 (actualizado 2025) 🟡③🌐 .- Análisis práctico de PEPs 517, 518 y 621 en herramientas como Poetry, con énfasis en backends modernos.
  7. Curso sobre desarrollo de un gestor de paquetes python que use poetry como backend 🟡③ .- Roadmap del curso de MetsuKe, con Módulo 1.3 dedicado a la implementación de estos PEPs en wrappers como MetsuDepManager.

Referencias Bibliográficas Críticas o de Refutación

  1. Pain points of moving to Poetry? (Discusión en Reddit) 🟡③🌐 .- Hilo comunitario que critica la no conformidad inicial de Poetry con PEP 621, destacando problemas de compatibilidad legacy hasta v2.0.
  2. Python Package Manager Comparison (DEV Community) 🟡③🌐 .- Comparativa que señala como limitación la parcial adherencia de Poetry a PEPs, comparado con herramientas más estrictas como Hatch.
  3. What's the difference between the tool.poetry and project tables in pyproject.toml? (Stack Overflow) 🟡③🌐 .- Debate sobre la dualidad de secciones en Poetry, criticando su migración lenta a PEP 621 y el uso de formatos custom.
  4. Navigating the Python Packaging Landscape: Pip vs. Poetry vs. uv (Medium) 🟡③🌐 .- Artículo que refuta la superioridad absoluta de Poetry en PEPs, apuntando a lentitud en resolución de dependencias y adopción incompleta hasta 2025.
  5. Vídeo: Is Python making Poetry REDUNDANT?! (YouTube, Very Academy) 🟡③🌐 .- Análisis que cuestiona la relevancia de Poetry ante PEPs como 735, destacando limitaciones en editable installs y grupos de dependencias pre-v2.0.
  6. poetry add, but for PEP 621? (Discusiones Python.org) 🟡③🌐 .- Conversación que critica la falta de comandos nativos para editar secciones PEP 621 en Poetry, proponiendo herramientas externas como solución temporal.

One More Thing

Un escenario de retrocomputación del siglo 24

¡Desbloquea el poder de MetsuOS y descubre que la privacidad y la seguridad son la clave para desencadenar tu verdadero potencial en línea!

Contenido registrado en Safe Creative

Logo Safe Creative
¡Usa el código de promocional 7ZYM4Z y ahorrate unos eurillos en tu suscripcion de Safe Creative!

MetsuOS Needs You!

Apoyanos en este proyecto difundiendolo en tus redes, o mejor, haznos una donación a la cuenta paypal para poder dedicar más tiempo y recursos a el. No olvides comentarnos que parete te interesa más junto con tu donación.

En este momento, además de mantener los servicios, estoy centrado en crear la siguiente iteración del software que me permite hacer todo esto y creando una biblioteca personal física para poder contrastar contenido.

Sobre el sistema de validez de un contenido en MetsuOS

Empezando a incorporar los niveles de validación de un contenido (también llamada sabiduría o niveles de conocimiento) ⚫🔴 🟡 🟢 🔵⚪ ¿Qué són?

Sobre la categorización de los tipos de conocimiento

La Metsukeología (de Metsuke vision global y logos conocimiento) es la ciencia que estudia el conocimiento como un conjunto potencial de conocimiento del que podemos obtener, procesar o percibir partes concretas dentro de un marco contextual específico, y cuyo contexto general real está muy por encima de lo que somos capaces, como especie, de percibir, procesar e integrar de forma completa (definición en progreso).

La Metsucología (de Metsu aniquilación - en este contexto en forma de colapso - , logos conocimiento) es la ciencia que estudia como extraemos verdades percibidas - colapsadas - como conocimiento desde nuestra perspectiva real (tanto epistemológico como gnoseológico) al tomar una parte específica del conocimiento metsukeológico potencial enmarcado en un contexto concreto, obligando a colapsar el conocimiento potencial en conocimiento específico (definición en progreso).

Mas sobre el contexto

DISCLAIMER: Mi consideración de anticientífico respecto al consenso científico es una hipotesis de trabajo propia, que supone que toda asignación de validez, incluso aquella derivada de la conclusión por acumulación de evidencia NO debe ser supeditada a debate, ni acuerdo, debe ser algo probabilistico sin intervención del ego humano. Podría estar equivocado y, en este punto, es donde se aplicaría entonces ese mismo consenso que ahora considero no valido (incluso dañino)

Existen indicadores para algunas cuestiones adicoinales como los siguientes:

Cuando hablamos de un contenido que incluye un texto que hace referencia a otro.

También aplicaremos el Sistema de fiabilidad de fuentes y credibilidad de contenidos de la OTAN 🔴②, este sistema incluye una valoración de la fiabilidad de la fuente de A a F (siendo A la de mayor fiabilidad) y una varloración de credibilidad del contenido de 1 a 6 (siendo 1 la mayor credibilidad).

En MetsuOS la agregaremos al final uniendo amos valores como si fuera una coordenada. Por ejemplo: ⚫①-D4 o 🟡③-B2. Esto ayudarña a contextualizar la información sobre la solidez del conocimiento al que se hace referencia en cada momento.

Hay que tener en cuenta que, cuando hay elementos subjetivos o parcialmente subjetivos, el punto de referencia seré yo mismo. Quizá más adelante pueda objetivizar esto más (seria lo deseable), pero en tanto no tenga herramientas que me lo permitan, debo ceñirme al principio de honestidar intelectual, y esperar que mis sesgos dañen lo menos posible la información (en parte este es el nudo gordiano que pretendo resolver, y por ello es dificil resolverlo a priori).

Así de forma resumida, podríamos decir que esta definición es nivel 🔴② (Rojo2 xD) ¿Crees que me dejo algo? Si es así por favor ayudame a mejorarlo contactándome a través de X (Twitter) en mi cuenta, @metsuke 🌐

Consulta la versión completa de la descripcion en ⚫🔴🟡🟢🔵⚪ (🔴②) Un poco más de detalle