uv lock reports “No solution found” when it cannot choose package versions that satisfy all active requirements at once. The resolver’s full “Because…” explanation is the best starting point: follow its constraints back to your project declarations, then make the smallest change that matches the project’s intended dependencies and supported environments. The message alone does not identify a defective package or prove that uv.lock is stale.
What “No solution found” means
Dependency resolution turns requested packages into specific versions while recursively checking the requirements those packages impose. A solve fails when the active requirements cannot all be met by a compatible selection. For example, two direct dependencies may require incompatible versions of the same transitive package; if changing either direct dependency to another available version cannot resolve the conflict, the set is unsatisfiable. uv’s resolution guide explains this process and how the resolver describes conflicts.
As an Amazon Associate I earn from qualifying purchases.
Read the complete resolver output, not only its final line. Start at the first stated cause and follow each “Because…” inference. Note each package and version condition, distinguish a requirement declared by your project from one imposed by another package, and look for the point where demands on the same package cannot overlap. The explanation describes the requirements in this solve; it does not, by itself, show that a particular release is broken.
The dependency guide’s example, a project requiring httpx>9999 when available versions stop at 1.0.0b0, is an obvious unsatisfiable version bound. Real conflicts can span several transitive dependencies or apply only under particular Python or platform markers. The uv dependency guide shows the example.
#1 Best Overall
Trace the conflict through your project
- Keep the full error and identify the command. Record whether you ran
uv lock,uv sync, or a command using uv’s pip interface. Project locking and pip resolution can consider different environment scopes. - Map every “Because…” clause. For each package in the explanation, record who requires it and what version condition applies. Compare direct requirements with the transitive requirements shown in the chain, and find the package whose conditions cannot be satisfied together.
- Inspect every project requirement set. Check
[project].dependencies,[project.optional-dependencies],[dependency-groups], and workspace members inpyproject.toml. uv resolves project requirements, extras, dependency groups, and workspace members together for locking. An optional group can therefore block lock creation even if your usual install would not select it. - Check Python and platform conditions. Compare the project’s
requires-python, the affected dependency’sRequires-Python, and any environment markers in the requirements. Ask whether the conflict applies everywhere or only to one part of the declared support range. - Change the declaration that caused the conflict. Correct an impossible or outdated project requirement, or use the narrower remedy appropriate to the cause below. Avoid changing unrelated requirements simply because they appear near the end of the error.
- Resolve again and verify the intended scope. Check that locking succeeds and that the resulting declarations still reflect the Python versions, platforms, and dependency sets the project is meant to support.
Check whether universal resolution exposes a scope conflict
A project’s uv.lock uses universal resolution: uv aims to produce a lockfile that works across the operating systems, architectures, and supported Python versions covered by the project. This can be more restrictive than resolving for the one machine currently running the command. A package that has no usable distribution for part of the declared scope can prevent a valid universal solution. The pip interface, by contrast, can use platform-specific resolution by default. See uv’s explanation of universal and platform-specific resolution.
The project’s requires-python range is part of that scope. In its universal-resolution handling of dependency Requires-Python ranges, uv considers lower bounds and ignores upper bounds. A dependency requiring a newer Python than the project’s declared lower bound may therefore cause a conflict even if the current interpreter is newer. Check the exact range and markers in the resolver chain before changing either declaration.
If the project genuinely supports fewer environments, the tool.uv.environments setting can limit which environments uv considers. Its entries must be disjoint. This changes the environments covered by resolution; it is appropriate only when the project really does not intend to support the excluded environments, not as a way to hide a conflict while continuing to claim that support.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Choose a fix that matches the cause
| Cause | Appropriate change | What to keep in mind |
|---|---|---|
| A direct pin or range cannot be satisfied | Correct the requirement in pyproject.toml, using uv add or uv remove where appropriate. |
Choose a range that reflects actual compatibility; loosening a bound just to silence the error may admit versions the project cannot use. |
| A transitive package needs a narrower acceptable range | Use a constraint to narrow versions of a package already in the dependency graph. | A constraint does not add a package to the graph. Make sure the narrowed range remains compatible with all other requirements. |
| Extras or dependency groups are alternative configurations that are never installed together | Declare the intended conflict in [tool.uv].conflicts. |
uv resolves the conflicting sets separately. Trying to install both sets together still fails. |
| Dependency metadata is known to be inaccurate | Use an override to replace the package’s declared dependency metadata. | uv describes overrides as a last resort. Because the metadata no longer validates the relationship, establish compatibility independently. |
| Broad or missing lower bounds cause a slow search or admit unsuitable old releases | Add meaningful lower bounds that reflect the oldest compatible versions. | For library authors, uv recommends validating bounds with lowest-resolution testing. Its guide notes: “Lower bounds are not critical in the ‘happy path’, but they are important when there are dependency conflicts.” |
| A conflict affects only a Python version or platform the project does not support | Use applicable markers or adjust the declared environment scope, including tool.uv.environments when appropriate. |
Narrow the scope only if that accurately describes the project’s support commitments. |
For ordinary declaration changes, the dependency guide documents editing requirements with uv add and uv remove, or changing pyproject.toml directly. Existing locked versions generally remain preferred unless a new incompatible requirement calls for a change or an upgrade is requested; --upgrade explicitly seeks newer versions. A lock preference is not proof that the full graph is unsatisfiable. See dependency management and resolution and lock preferences.
Do not treat every failure as a corrupt lockfile
“No solution found” points to requirements that uv cannot satisfy together under the active solve. Start by inspecting the declarations, dependency chain, and environment scope; the official guidance does not establish deleting uv.lock as a general remedy. Once you have identified the cause, make the smallest honest change and verify that the project still supports the environments and dependency combinations it promises.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
