- A set of deps in
mix.exs
with a couple of pinned dependencies. This is the way Depfu ensures that on an update we get exactly the versions we want to upgrade to. This is likely in many cases to produce incompatible sets of pinned dependencies and thismix.exs
is an example. It pinsranch
to2.1.0
which is incompatible withbypass
which requests~> 1.3.0
. - A
mix.lock
that is currently not in sync with themix.exs
- Run
mix deps.update ranch
- This, if run first, does correctly identify the problem with the ranch dependency - Run
mix deps.get
- This, somehow, updates a bunch of packages but in the end builds a new lockfile that is out of sync with the mix.exs, with an old version ofranch
locked in. - Run
mix deps.update ranch
- This, now, runs successfully, without noting the problem and not changing anything on the lockfile
The difference with 1 and 3 seems to have to do with cached data, because removing the deps folder fixes the issue.
See .tool-versions for the Elixir and Erlang/OTP versions used when testing.