mix deps.update <transitive-dep> wrongly updates mix.lock if deps/ dir empty

[grzuy]

Elixir and Erlang/OTP versions

Erlang/OTP 27 [erts-15.1.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Elixir 1.17.3 (compiled with Erlang/OTP 27)

Operating system

Linux

Current behavior

Hey there 👋

$ mix new app1

Add a dependency to mix.exs that has at least one package dependency. Example used mint, which depends only on hpax.

$ mix deps.get
$ git add mix.exs mix.lock

$ rm -r deps
$ mix deps.update hpax

Actual behaviour

mix.lock is updated and the [:mix] manager value is removed for hpax.

$ git diff

diff --git a/mix.lock b/mix.lock
index bc2d7e8..004cc5b 100644
--- a/mix.lock
+++ b/mix.lock
@@ -1,4 +1,4 @@
 %{
-  "hpax": {:hex, :hpax, "1.0.1", "c857057f89e8bd71d97d9042e009df2a42705d6d690d54eca84c8b29af0787b0", [:mix], [], "hexpm", "4e2d5a4f76ae1e3048f35ae7adb1641c36265510a2d4638157fbcb53dda38445"},
+  "hpax": {:hex, :hpax, "1.0.1", "c857057f89e8bd71d97d9042e009df2a42705d6d690d54eca84c8b29af0787b0", [], [], "hexpm", "4e2d5a4f76ae1e3048f35ae7adb1641c36265510a2d4638157fbcb53dda38445"},
   "mint": {:hex, :mint, "1.6.2", "af6d97a4051eee4f05b5500671d47c3a67dac7386045d87a904126fd4bbcea2e", [:mix], [{:castore, "~> 0.1.0 or ~> 1.0", [hex: :castore, repo: "hexpm", optional: true]}, {:hpax, "~> 0.1.1 or ~> 0.2.0 or ~> 1.0", [hex: :hpax, repo: "hexpm", optional: false]}], "hexpm", "5ee441dffc1892f1ae59127f74afe8fd82fda6587794278d924e4d90ea3d63f9"},
 }

Expected behavior

Either

• No changes to the manager value in the mix.lock
• OR it returns an error if mix deps.update should not be run if deps/ not populated?

[grzuy]

In case this should be considered an invalid scenario for mix deps.update maybe is somewhat related with #13938 ?

[josevalim]

Yes, this is a bug. We will need to look deeper but mix deps.update should download the dependency, no? So we should be able to look into it and see that it is a [:mix] thingy?

[grzuy]

As far as I could debug, it's being caused by Hex remote converger not able to get the "manager" value in

https://github.com/hexpm/hex/blob/836c2eb2c2b25f9d9cbceb958e549f3a73b8c548/lib/hex/mix.ex#L177-L195

because of the deps/hpax/.hex not there.

So, yes, making sure we fetch before solving the new lock guess would fix it...