Measuring dependency resolution bottlenecks in Poetry

Direct Answer

The most reliable method to isolate SAT-solver backtracking from network latency is to run poetry lock -vvv twice in succession: the first run populates the local metadata cache (cold cache), and the second run executes with a warm cache, effectively eliminating network round-trips. The time difference between the two runs quantifies network overhead, while the verbose output of the warm run reveals pure resolver activity.

How to Separate Resolver CPU Time from Network I/O

1. Cold-cache baseline: Clear the cache (typically ~/.cache/pypoetry on Linux/macOS, %LOCALAPPDATA%\pypoetry\Cache on Windows) and remove poetry.lock, then run poetry lock -vvv. Record total elapsed time.
2. Warm-cache measurement: Immediately run poetry lock -vvv again without changing any files. The second run reuses cached metadata; its duration reflects CPU-bound resolution only.
3. Compare: Subtract warm-run time from cold-run time to estimate the network contribution. If the warm run still takes many seconds, the bottleneck is in the resolver.

Verbose Output Indicators of Broad-Constraint Bottlenecks

In the -vvv output of a warm-cache run, look for these patterns that signal excessive backtracking caused by overly broad version constraints:

• Repeated candidate attempts for the same package: Consecutive lines showing the solver trying different versions of one dependency, followed by conflict/backtracking messages, indicate it is iterating through many candidates.
• High candidate counts: Messages reporting that a version is being selected from a large pool of candidates (hundreds) for a single dependency suggest the constraint range is too wide.
• Absence of network verbs: No Downloading, Requesting, or HTTP request lines during the slow phase confirms the delay is not network-bound. Network-bound stalls correlate with those fetch lines; resolution stalls do not.

Practical Verification Steps

1. Run the warm-cache poetry lock -vvv and capture the output to a file.
2. Search for repeated version-attempt or backtracking lines associated with a specific package.
3. Tighten the version constraint for that package in pyproject.toml (e.g., change ^1.0 to ~1.2, or pin an exact version).
4. Repeat the warm-cache run; a reduction in candidate-attempt iterations and total time confirms constraint breadth was the cause.

Assumptions and Uncertainty

• Assumes Poetry 1.8+ or 2.x; cache locations and exact log phrasing may differ in older versions.
• Cache persistence varies by OS and configuration; a nominally warm cache may still trigger network requests if the lock file was deleted or cache entries expired.
• Very large dependency graphs can cause high memory usage that mimics a CPU bottleneck due to swapping; monitor resident memory during the run.
• Exact log wording is version-dependent; verify against your installed Poetry before scripting log parsing.

One Missing Diagnostic Detail

What Poetry version and operating system are you using? This affects cache paths, log format, and resolver behavior, so it changes which indicators you should expect to see.