poetry review

poetry review

Poetry is a Python project manager that resolves and locks dependencies, creates isolated environments, builds packages, and publishes them. It puts work that often spans pip, virtualenv, build frontends, and several packaging files behind one command-line tool and a pyproject.toml file.

python-poetry/poetry · ★ 34,296 · Python · 2.4.2 · reviewed by Keyoor

We ran it

Cloned commit e33ce99 on 01 Sept 2026, run in a fresh sandbox (3 CPUs, 8 GB, Debian container, python toolchain). How we test →

Lab card: what happened when we ran poetry

Screenshot of poetry (python-poetry.org)

Install	✓ · 67s	70 packages · 86 MB
Build	✓ · 9s
Tests	✗ · 6s	ran, no count parsed
Known vulns	0	(pip-audit)
Repo	1003 files	~79,923 lines of source · 8.7 MB · 6 CI workflows · tests dir

Answers from our run

Does poetry build from source?

Dependencies installed in 67 seconds (70 packages), and the build succeeded in 9 seconds. We cloned commit e33ce99 into a clean Debian container with 3 CPUs and no project-specific setup.

Do poetry's tests pass?

The test command failed in our container, and its output did not report a pass or fail count.

Does poetry have known vulnerabilities in its dependencies?

pip-audit found none in the dependency tree at the time of our run.

Who should not use poetry?

Mixed-tool teams that expect private source declarations to travel with standard package metadata: Poetry's docs say its source entries are Poetry-specific and pip ignores them.

What are the alternatives to poetry?

uv, PDM, Pipenv. Our Poetry checkout installed 70 packages in 67 seconds and built in 9 seconds, but its test command stopped after 6 seconds because responses was missing.

Who it’s for

Python application teams that want one committed lock file and repeatable project environments.

Library maintainers who want dependency management, wheel and sdist builds, and publishing in one tool.

Teams willing to standardize local development and CI around Poetry's commands.

Projects that need dependency groups or authenticated private package sources.

Who it’s NOT for

Mixed-tool teams that expect private source declarations to travel with standard package metadata: Poetry's docs say its source entries are Poetry-specific and pip ignores them.

Non-root container builds that depend on project-required plugins without testing that exact image: open issue 10341 reports a plugin appearing to install while its command remains unavailable.

Root container installs on older Python 3.10 or 3.11 patch releases that must consume source distributions: open issue 11036 reports a Poetry 2.4.2 extraction regression.

Projects with architecture-specific package sources that cannot tolerate an unbounded lock step: open issue 10965 documents an infinite solver loop in one such Poetry 2.4.1 setup.

Developers who want the project manager to choose and obtain Python automatically during a normal install: the basic-use docs say a compatible interpreter must already be available.

Setup reality

Our commit e33ce99 sandbox install succeeded in 67 seconds, adding 70 packages and using 86 MB. The build passed in 9 seconds. Tests stopped after 6 seconds with exit 4 because tests/conftest.py could not import responses. Pip-audit found 0 known vulnerabilities.

Public PyPI use needs no account or service beyond network access and a compatible Python interpreter. Private sources add repository URLs plus a username and password, token, or certificate. Publishing also needs package-index credentials, and Poetry may store them through the system keyring.

Poetry creates a virtual environment by default and chooses a compatible interpreter it can find. Project source entries are Poetry-specific, so pip does not preserve that routing. Plugins live in Poetry's own environment, which makes their installation path part of a reproducible CI or container setup.

One pyproject.toml replaces 5 packaging files

Poetry folds the jobs once spread across 5 files into one project definition. Its README explicitly names setup.py, requirements.txt, setup.cfg, MANIFEST.in, and Pipfile, then shows standard project metadata beside Poetry-specific dependency settings. The command line can create a package skeleton, add dependencies, update the lock, build a wheel or source distribution, and publish it. That is the appeal: one tool owns the path from a new checkout to a released Python package.

This breadth comes with a sizeable codebase. Our commit e33ce99 checkout contained 1,003 files, about 79,923 lines of source, and 8.7 MB before installation. The repository has a tests directory and 6 CI workflow files, which fits a mature packaging tool whose behavior crosses operating systems, Python releases, indexes, and archive formats. There is no Dockerfile, so container users still have to translate the installation and credential guidance into their own base image.

Python 3.10 or newer gets package and non-package modes

Poetry's source at commit e33ce99 requires Python 3.10 or newer, while projects declare their own supported Python range. Package mode expects build metadata and installs the project itself in editable form. Non-package mode skips the distribution metadata and installs only dependencies. That split lets an application team use the resolver and environment handling without pretending every repository will become a wheel, while library maintainers keep the build and publish path.

A lock file is the practical center of the workflow. Poetry resolves declared constraints and records exact selections so another poetry install can recreate them. Dependency groups can separate test or documentation tools, and optional groups can be layered for CI jobs or development roles. Our sandbox added 70 packages and used 86 MB, a modest result for the tool itself. Your project dependencies are a separate cost, and Poetry still needs a compatible interpreter on the machine.

What happened when we ran it

Our sandbox installed Poetry in 67 seconds and built it in 9 seconds. The measurement setup used commit e33ce99, 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, an unprivileged container, and no secrets. Installation added 70 packages and occupied 86 MB. Those figures describe working on Poetry's own repository, not the time needed to install dependencies for an unrelated Python application.

The test command failed with exit 4 after 6 seconds. Pytest did not reach the suite because importing tests/conftest.py raised ModuleNotFoundError: No module named 'responses'. The log establishes the missing module and nothing more, so we are not assigning a cause beyond that import failure. Pip-audit reported 0 known vulnerabilities in the installed environment. The build result is useful, but this checkout did not produce a passing test run in our stated container.

Poetry 2.4.2 needs explicit private-index policy

Poetry 2.4.2 can use PyPI without credentials and can add private package sources with primary, supplemental, or explicit priority. Authenticated sources need HTTP credentials, a token, or certificates, while publish targets are configured separately. The docs also warn that shell history can retain credentials and that a netrc file may conflict with Poetry's configured authentication. Teams should decide where repository routing lives and how CI supplies secrets before adopting the commands wholesale.

Source routing has a portability catch. The documentation says Poetry's project source entries do not become core package metadata, so pip ignores them when it installs the resulting project. A dependency expected from a private or explicit source may therefore be looked up elsewhere by another installer. The repository has 6 CI workflow files but no Dockerfile to prescribe secret handling. Mixed Poetry and pip environments need an independent index policy rather than assuming pyproject.toml carries the whole decision.

1 open plugin report matters to non-root images

One open issue, number 10341, reports that a project-required export plugin appeared to install under a non-root Amazon Linux container but the export command remained unavailable. The report is specific to its image and Poetry 2.1.2, so it does not prove every plugin install is broken. It does show why a container test should invoke each required plugin command instead of trusting the preceding installation message. Poetry plugins run inside Poetry's environment, separate from the project environment.

Solver behavior also deserves a representative lock case. Open issue 10965 describes an infinite loop under Poetry 2.4.1 when a project combined architecture-specific Torch sources with another dependency; poetry lock --regenerate was the reported workaround. That is a narrow configuration, yet it is exactly the sort of configuration that makes teams choose Poetry. Our 9-second build says nothing about resolver time on a large application graph, so CI should put a timeout around lock regeneration and retain the last known-good lock file.

34,296 stars accompany current fixes and regressions

GitHub showed Poetry at 34,296 stars, with the last push on August 31, 2026. The same week had active issues and pull requests, and release 2.4.2 was published on August 29. Its notes include fixes for 2 path-traversal problems in download and source-distribution extraction. That release history and the recent issue updates show active maintenance rather than a repository coasting on an old tag.

The combined open count was 571 issues and pull requests, which is a work queue rather than a bug total. One fresh report describes a 2.4.2 source-distribution extraction failure when running as root on older Python 3.10 and 3.11 patch versions. Mature does not mean uneventful here. Poetry is still the conservative choice for teams that value its packaging model, provided they pin its version, test private sources and plugins in CI, and treat lock-file changes as reviewed artifacts.

Alternatives

Project	What it is	Pick it when
uv gh↗	A fast Rust-based Python package and project manager with interpreter management.	pick this instead when install speed and managed Python versions matter more than staying with Poetry's established workflow.
PDM	A standards-focused Python package manager built around pyproject.toml and lock files.	pick this instead when you want a similar all-in-one workflow with different environment and plugin choices.
Pipenv	A Python environment and dependency manager centered on Pipfile and Pipfile.lock.	pick this instead when your organization already uses Pipfile and does not need Poetry's package-building model.