CodeVetter · Repo Unpack · Extension points
python-poetry/poetry
Commands and plugins provide the clearest intentional extension surfaces. Repository construction, priority handling, and configuration normalization centralize additional integration choices. Build backend hooks and package-specific build constraints extend packaging behavior. Some interfaces expose mutable internal state, and plugin documentation explicitly warns that the public API is not stable.
- Built-in commands plug into COMMANDS and load_command: space-separated names map to dotted modules and title-cased Command classes, instantiated lazily.
- ApplicationPlugin uses the poetry.application.plugin entry-point group and registers command classes through command_loader.register_factory during activate.
- Generic plugins implement activate(poetry, io) and may manipulate project configuration and state; Factory loads and activates them after constructing the project repository pool.
- PluginManager discovers importlib.metadata entry points, checks classes against Plugin/ApplicationPlugin, instantiates them, and dispatches activation arguments; --no-plugins gates application loading.
- Project-required plugins use dependency syntax under tool.poetry.requires-plugins; ProjectPluginCache hashes the declaration with Python/Poetry versions and redirects purelib/platlib installation into .poetry/plugins.
- Factory.create_package_source selects PyPiRepository, LegacyRepository, or SinglePageRepository; RepositoryPool centralizes primary/supplemental/explicit priority and named-source lookup.
- Config.default_config and Config.get centralize settings and POETRY_* overrides, including package-specific installer.build-config-settings; new settings must account for normalization and nested lookup.
- BuildHandler selects BUILD_FORMATS or isolated backend builds; Factory converts per-package build constraints into dependency objects, and Chef passes constraints and config settings to wheel/editable builds.