How do you read pip's ResolutionImpossible report to find which requirements actually conflict?

## What the report is telling you When pip's resolver proves that no set of versions satisfies everything, it fails with a conflict report — the failure pip's internals call *resolution impossible*. A representative one: ```text ERROR: Cannot install pkg-a and pkg-b==2.0 because these package versions have conflicting dependencies. The conflict is caused by: The user requested shared-lib==1.4 pkg-a 3.1 depends on shared-lib>=2.0 pkg-b 2.0 depends on shared-lib<1.5 To fix this you could try to: 1. loosen the range of package versions you've specified 2. remove package versions to allow pip to attempt to solve the dependency conflict ``` Read it in three passes. **Pass one: who is asking.** Every line in the conflict block is a *requester*. `The user requested ...` means the requirement came from you — a command-line argument or your requirements input. Every other line has the form `<requester> <its version> depends on <range>`, and the requester's own version matters: `pkg-a 3.1` is the specific release whose metadata carries that range, which tells you immediately whether a different `pkg-a` release might carry a different one. **Pass two: intersect the ranges.** Collect the ranges demanded of the same distribution and ask whether any version satisfies all of them. In the example, `>=2.0` and `<1.5` are disjoint, and the user's `==1.4` satisfies one of them and not the other. That is the whole conflict. If the intersection is non-empty but no release exists inside it, you have a different problem — a gap in the release history rather than contradictory constraints. **Pass three: decide whose constraint is soft.** Your own pin is usually the softest, which is why pip's first suggestion is to loosen what you specified. An upper cap in a third party's metadata is harder, but not immovable — caps are frequently defensive and stale, and a newer release of that requester often widens them. ## Finding the requester the report does not name Often the distribution at the centre of the conflict is one you have never heard of, because it is transitive. For anything already installed, `python -m pip show <name>` prints both what it requires and what requires it, which walks the chain in the direction you need. For metadata you want to inspect programmatically, `importlib.metadata` reads the same installed `.dist-info` records from the standard library. For candidates that are not installed, the report itself is the metadata: it already printed the requester version and its range. ## When the report names the wrong culprit This is the subtlety worth carrying into an interview. The resolver backtracks, so by the time it gives up it may have wandered far from your actual requirements, and the combination it prints is the last one it tried, not necessarily the minimal explanation. Two habits fix it: * **Reduce the problem.** Try to install the two suspected requesters alone in a scratch environment. If they conflict on their own, you have the minimal reproduction; if they do not, something else in your requirement set is forcing the situation. * **Turn up verbosity.** Verbose output shows the search as it happens, which reveals which requirement kept pushing the resolver backwards before it failed. ## The failure that looks similar but is not a conflict `No matching distribution found for shared-lib==1.4` is not a conflict report. It means no candidate is installable at all: the version does not exist on the configured index, or every candidate is excluded by its declared `Requires-Python` range or by platform compatibility — for example, on a recently released interpreter for which no compatible wheel has been published. The diagnosis is completely different: you check what the index offers and what your interpreter is, rather than hunting for a contradictory pair. ## After you have read it The report tells you what is unsatisfiable; it does not tell you which constraint to give up. That decision — loosen your own pin, upgrade the capping requester, drop a dependency, or separate the two consumers — is the judgement call, and it belongs to whoever understands what the two consumers are for. Reading the report accurately is what stops that decision from being made by guesswork.