CodeVetter · Repo Unpack · System map
python-poetry/poetry
The executable frontend is a Cleo application with lazy command loading and event-driven environment and installer setup. Factory connects poetry-core project parsing to Poetry-owned configuration, repositories, plugins, and lock storage. Resolution, operation planning, artifact preparation, and environment mutation occupy separate modules. Distribution is through Python packages and a console script; the inspected CI includes lock validation, build/install smoke checks, typing, and tests.
- Both the installed poetry console script and python -m poetry reach poetry.console.application.main, which constructs Application and calls run().
- Application uses Cleo, registers COMMAND listeners for logging, environment setup, and installer setup, and supplies lazy factories for the COMMANDS table.
- The package requires Python >=3.10,<4.0, pins poetry-core 2.5.0, and declares poetry.core.masonry.api as its PEP 517 build backend.
- Factory.create_poetry validates requires-poetry, delegates project creation to BaseFactory, then attaches Locker, Config, a repository pool, and optional generic plugins.
- Solver owns Provider and invokes mixology.resolve_version; VersionSolver maintains incompatibilities and a PartialSolution while propagating constraints and choosing package versions.
- Installer reads installed packages through InstalledRepository.load and delegates mutations to Executor, while Transaction supplies environment-specific operations.
- Persistent state includes project poetry.lock, global config.toml/auth.toml, optional project poetry.toml, artifact caches, and virtual environments under a configurable cache path.
- CI declares poetry check --lock, pipx-based build/Twine/install smoke checks, poetry run mypy, and poetry run pytest --integration -v.