Hex 2.0 produces conflicts between mix.exs and mix.lock

[halfbyte]

Here's a repo containing a set of mix.exs with some pinned deps and a mix.lock that is not in sync with that mix.exs.

Steps to Repro:

1. Check out said repro
2. Run mix deps.get

Expected behaviour:

• Mix should complain about a dependency conflict and fail

Actual behaviour:

• Mix does it's thing resulting in no change to the mix.lock and not complaining, resulting in a clear conflict between the deps in mix.exs and the state in mix.lock

Mix 1.x correctly shows a dependency conflict (At least for this particular, relatively simple case)

The repo contains a couple of extra steps to show that even mix deps.update would not complain (at least if mix deps.update has run once.

We (Depfu.com) have managed to work around in this bug, we think, but this can lead to some really odd results in real life, we think.

[ericmj]

Thanks for the great bug report with a repo that reproduces the issue. I believe this has been fixed in main, you can try it by running mix archive.install github hexpm/hex.

[halfbyte]

@ericmj This does seem to be the case, yes. Whee!

Allow me to add: Thanks for doing such a good job with the Hex 2.0 dependency resolver. We had a few customers where we had to restrict service due to the problems with the Hex 1.x resolver and resource usage. This at least was fixed completely with Hex 2.0 and we are very happy about that.

Feel free to close this bug (alternatively I will close it when 2.0.1 is released)