Two of your service's dependencies demand incompatible versions of one shared library — how do you resolve it?

## The situation A warehouse pick-list builder handles a peak of about **1,200 requests per minute**, and under that peak it hits a race on shared state inside a library it depends on transitively. The race is fixed in that library's newer release — but another of the service's dependencies declares an upper cap that excludes it, so the install resolves to the buggy version or fails outright. Staying put is not free: the defect is real and it bites at peak. This is the standard shape of the senior version of this problem, and the interesting part is not the resolver, it is the decision. ## Step 0: establish the facts before touching anything Read the actual metadata rather than the folklore. The conflict report names the capping requester and its version; check the requester's release history for a version that widened the range. Confirm which constraint is *yours* — a surprising share of conflicts are caused by an exact pin someone added to your own requirements two years ago for a reason nobody remembers. ## The ladder, cheapest first **1. Upgrade the capping dependency.** Upper caps are frequently defensive: a maintainer wrote `<2` before the shared library's 2.0 existed and widened it two releases later. If a newer release removes the cap, you are done, and it is fully reversible. **2. Loosen your own pin.** If the cap is yours, the fix is to widen or remove it and let your test suite decide whether the newer version is safe. Cheap, reversible, and it removes a constraint the resolver was never obliged to respect for a good reason. **3. Test whether the cap is true, then fix it upstream.** Build a scratch environment with the cap bypassed, install the newer shared library, and run your suite plus a load test at your peak. If the capping distribution genuinely works against the newer version, send the maintainer that evidence and a change widening the range, and carry a local override in your own environment definition until it lands. You have converted a permanent problem into a temporary one. **4. Drop the dependency.** Look at what the capping distribution is actually used for. If it is one helper function or a thin wrapper, deleting it and inlining the behaviour is often the cheapest permanent fix available, and it reduces the dependency count that produced the conflict in the first place. **5. Vendor it.** Copy the capping distribution's source into your own tree under your own namespace so it is no longer resolved at all. This works, and it is sometimes the right answer for small, stable, effectively unmaintained code. Be clear-eyed about the price: you now own its security fixes, its bug reports and its future compatibility, and your scanners no longer recognise it as a known dependency with known advisories. Vendoring is an ownership transfer, not a trick. **6. Split the consumers.** The single-version rule is per environment, so putting the capping consumer behind a process boundary — a separate worker, service or isolated tool environment — removes the conflict entirely. It costs a real interface, a deployment unit and the operational burden that comes with it. Justified when the two consumers are genuinely separate concerns; overkill when they are not. **What is not on the ladder:** installing with dependency checking bypassed and shipping the result. That converts a loud build-time failure into a quiet runtime one — an `ImportError` or an `AttributeError` raised at peak, in production, in a code path you did not exercise. If you do bypass checks to *experiment*, do it in a scratch environment and never in the artefact you deploy. ## How to choose Two axes decide it. **Reversibility:** an upgrade or a loosened pin can be undone in a commit; vendoring and process-splitting cannot, cheaply. **Ownership:** every rung past the third moves maintenance from someone else onto your team, permanently. Prefer the highest rung on the ladder you can reach, and when you have to descend, write down why, what would let you climb back, and who checks. “Revisit when the capping distribution's next release ships” is a real, checkable trigger; “temporarily vendored” with no trigger is how a fork becomes forever. And in the specific case above, the deadline argument cuts both ways: the race at peak is a production defect, so “we will wait for upstream” needs a mitigation attached — rate limiting the affected path, or a temporary override in the deployed environment — rather than being a decision to live with the bug indefinitely.