MetsuOS

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

Arquitectura Interna de un Gestor de Paquetes Python que Usa Poetry como Backend 🟡③

Arquitectura Interna de un Gestor de Paquetes Python que Usa Poetry como Backend

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

Introducción

Crear un gestor de paquetes Python desde cero que delegue la mayor parte del trabajo pesado a Poetry (específicamente a poetry-core) es una estrategia muy potente para aprender cómo funcionan internamente herramientas modernas como Poetry, uv, pipenv o pdm.

En lugar de reinventar la rueda, nos apoyamos en componentes ya probados y maduros de Poetry, pero los orquestamos con nuestra propia capa de alto nivel. Esta arquitectura nos permite tener un gestor ligero, extensible y perfectamente reproducible, ideal tanto para proyectos educativos como para entornos empresariales con requisitos muy específicos.

Veamos los cinco pilares fundamentales de esta arquitectura: Core, Solver, Locker, Installer y Builder.

1. Core – El director de orquesta

El Core es el punto de entrada único del gestor y quien entiende los comandos del usuario (add, install, remove, lock, build, …).

Sus tareas principales son:

class GestorCore:
    def __init__(self, ruta_proyecto: Path = Path.cwd()):
        self.poetry = Factory().create_poetry(ruta_proyecto)  # poetry-core hace el trabajo duro
        self.solver    = ResolverDependencias(self.poetry)
        self.locker    = Bloqueador(self.poetry)
        self.installer = Instalador(self.poetry)
        self.builder   = Constructor(self.poetry)

    def install(self, solo_produccion: bool = False):
        if not self.locker.esta_fresco():
            self.resolver_y_bloquear()
        self.installer.ejecutar(produccion=solo_produccion)

Ventaja práctica: el Core puede tener apenas 150-300 líneas y ya ofrece una CLI completa.

2. Solver – El cerebro matemático

El Solver resuelve el grafo de dependencias. En Poetry se basa en ResolveLib + un algoritmo propio de “preferred versions”.

Funciones clave:

En nuestro gestor podemos usar directamente:

from poetry.puzzle.provider import Provider
from poetry.core.packages.project_package import ProjectPackage

provider = Provider(self.poetry.package, self.poetry.pool, self.poetry.locker)
transaction = provider.solve(self.poetry.package.python_versions)

3. Locker – La garantía de reproducibilidad

El Locker escribe y lee el archivo poetry.lock (o un formato propio compatible).

Responsabilidades:

Poetry ya ofrece una implementación muy robusta que podemos reutilizar casi sin cambios.

4. Installer – El operario que ensucia las manos

El Installer descarga wheels/sdists y los coloca en el entorno virtual.

Características importantes que heredamos de Poetry:

from poetry.installation.executor import Executor

executor = Executor(env=self.poetry.env, pool=self.poetry.pool, config=self.poetry.config)
executor.execute(operations)  # operations vienen del Locker

5. Builder – El empaquetador PEP-517/518

El Builder genera los artefactos distribuibles (*.whl y *.tar.gz).

En Poetry este trabajo lo hace exclusivamente poetry-core, que implementa el build-backend estándar.

Solo tenemos que invocar:

from poetry.core.masonry.builders.wheel import WheelBuilder
from poetry.core.masonry.builders.sdist import SdistBuilder

WheelBuilder(self.poetry).build()   # crea dist/mi_paquete-1.0.0-py3-none-any.whl
SdistBuilder(self.poetry).build()   # crea dist/mi_paquete-1.0.0.tar.gz

Esto nos da soporte automático para include/exclude, data-files, entry-points, etc., sin escribir ni una línea de setup.py.

Referencias bibliográficas que apoyan esta arquitectura

  1. Repositorio oficial de Poetry (código fuente de todos los componentes descritos) 🟡③🌐 .- Repositorio oficial de GitHub para Poetry, herramienta de gestión de dependencias y empaquetado en Python que simplifica el uso de pyproject.toml para declaraciones de dependencias, restricciones de versión y grupos opcionales.
  2. Repositorio de poetry-core (el build-backend puro, sin CLI) 🟡③🌐 .- Repositorio oficial de GitHub para poetry-core, implementación ligera del backend de construcción PEP 517 para proyectos gestionados por Poetry, permitiendo builds eficientes sin dependencias completas de Poetry.
  3. Artículo oficial de la PSF – “PEP 517 – A build-system independent format for source trees” 🟡③🌐 .- Documento oficial PEP 517 que define un formato independiente del sistema de construcción para árboles de origen de paquetes Python, utilizando pyproject.toml para backends y requisitos de build.
  4. Artículo oficial de la PSF – “PEP 518 – Specifying Minimum Build System Requirements” 🟡③🌐 .- Documento oficial PEP 518 que especifica cómo declarar dependencias del sistema de construcción en pyproject.toml, usando la tabla [build-system] para requisitos como setuptools.

Referencias que cuestionan o presentan alternativas a usar Poetry como backend

  1. Astral – Documentación oficial de uv (el nuevo resolver escrito en Rust, 10-100× más rápido) 🟡③🌐 .- Documentación oficial de uv, gestor de paquetes y proyectos Python extremadamente rápido escrito en Rust, que reemplaza herramientas como pip, Poetry y virtualenv, con características como lockfiles universales, workspaces y benchmarks que muestran 10-100x más rápido que pip.
  2. Ofek Lev – “Hatch project (alternativa completa que no depende de Poetry) 🟡③🌐 .- Hatch es un gestor de proyectos Python moderno y extensible, independiente de Poetry, con sistema de builds reproducibles, gestión de entornos robusta, soporte para UV, análisis estático con Ruff y CLI responsiva hasta 3x más rápida.

Con estas referencias puedes contrastar objetivamente las ventajas y desventajas de basar tu gestor en Poetry frente a las nuevas generaciones de herramientas (uv, rye, pixi, etc.).

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