`mix deps.update [DEP]` does not update the package

[kevinschweikert]

Elixir and Erlang/OTP versions

Erlang/OTP 28 [erts-16.3.1] [source] [64-bit] [smp:11:11] [ds:11:11:10] [async-threads:1] [jit]

Elixir 1.19.4 (compiled with Erlang/OTP 28)

Operating system

macOS Sequoia 15.7

Current behavior

I see there is an update possible for the image library in my project. When i run mix deps.update image it just updates castore but not the image library. After that it's a no-op.
I've also tried with 1.20-rc*/OTP-29 but that also does not update the image dependency.

> mix hex.outdated
Dependency              Only      Current  Latest  Status               
...        
image                             0.63.0   0.64.0  Update possible      
...       

> mix deps.update image
Resolving Hex dependencies...
Resolution completed in 0.224s
Unchanged:
  alarmist 0.4.1
  argon2_elixir 4.1.3
  bandit 1.10.4
...
Upgraded:
  castore 1.0.17 => 1.0.18

Expected behavior

The image library get's updated to 0.64.0

[kipcole9]

Perhaps you're pinned to 0.63.0 in your mix.exs? Otherwise I don't know what would prevent hex from updating it (and I don't have any control of that). I'll set up a test app to check as well.

[kevinschweikert]

This is in my current mix.exs:

      {:image, "~> 0.43"},

That should allow 0.64.0 and the output of mix hex.outdated suggests the same.

[josevalim]

If it is not being updated, it is because there is another dependency holding it to 0.63, so you need to update it too.

[josevalim]

If you can, please provide a mix.exs and mix.lock that reproduces it, but most likely something is depending on it. Use mix deps.tree to see the tree too.

[SteffenDE]

I think I've seen something like this with a different dependency too in the past. What's weird is that it explicitly says "Update possible". Shouldn't it say something else if

there is another dependency holding it to 0.63

?

[kevinschweikert]

I am still trying to reproduce it in a new mix project because the current project has a bunch of dependencies and i want to avoid that noise. But whatever outcome, i would've expected an informative message, why the solver cannot update the dependency when running the explicit update command or as Steffen said in the outdated info.

[kevinschweikert]

I could reproduce it. image has an optional dependency to fine and lazy_html also. This prevents the update of image.

mix.exs

defp deps do
    [
      {:image, "~> 0.43"},
      {:lazy_html, ">= 0.0.0", only: :test}
    ]
  end

mix.lock

%{
  "cc_precompiler": {:hex, :cc_precompiler, "0.1.11", "8c844d0b9fb98a3edea067f94f616b3f6b29b959b6b3bf25fee94ffe34364768", [:mix], [{:elixir_make, "~> 0.7", [hex: :elixir_make, repo: "hexpm", optional: false]}], "hexpm", "3427232caf0835f94680e5bcf082408a70b48ad68a5f5c0b02a3bea9f3a075b9"},
  "elixir_make": {:hex, :elixir_make, "0.9.0", "6484b3cd8c0cee58f09f05ecaf1a140a8c97670671a6a0e7ab4dc326c3109726", [:mix], [], "hexpm", "db23d4fd8b757462ad02f8aa73431a426fe6671c80b200d9710caf3d1dd0ffdb"},
  "image": {:hex, :image, "0.63.0", "03efcfeb1cfaac10d6ab364acce2bfa35e6b33b08947f291fdc17df796b36226", [:mix], [{:bumblebee, "~> 0.6", [hex: :bumblebee, repo: "hexpm", optional: true]}, {:evision, "~> 0.1.33 or ~> 0.2", [hex: :evision, repo: "hexpm", optional: true]}, {:exla, "~> 0.9", [hex: :exla, repo: "hexpm", optional: true]}, {:jason, "~> 1.4", [hex: :jason, repo: "hexpm", optional: true]}, {:kino, "~> 0.13", [hex: :kino, repo: "hexpm", optional: true]}, {:nx, "~> 0.10", [hex: :nx, repo: "hexpm", optional: true]}, {:nx_image, "~> 0.1", [hex: :nx_image, repo: "hexpm", optional: true]}, {:phoenix_html, "~> 2.1 or ~> 3.2 or ~> 4.0", [hex: :phoenix_html, repo: "hexpm", optional: false]}, {:plug, "~> 1.13", [hex: :plug, repo: "hexpm", optional: true]}, {:req, "~> 0.4", [hex: :req, repo: "hexpm", optional: true]}, {:rustler, "> 0.0.0", [hex: :rustler, repo: "hexpm", optional: true]}, {:scholar, "~> 0.3", [hex: :scholar, repo: "hexpm", optional: true]}, {:sweet_xml, "~> 0.7", [hex: :sweet_xml, repo: "hexpm", optional: false]}, {:vix, "~> 0.33", [hex: :vix, repo: "hexpm", optional: false]}], "hexpm", "63b39a312f889bb61a04a4957977a7cd3fa23974ff56de3feebf46f69c5fa60e"},
  "phoenix_html": {:hex, :phoenix_html, "4.3.0", "d3577a5df4b6954cd7890c84d955c470b5310bb49647f0a114a6eeecc850f7ad", [:mix], [], "hexpm", "3eaa290a78bab0f075f791a46a981bbe769d94bc776869f4f3063a14f30497ad"},
  "sweet_xml": {:hex, :sweet_xml, "0.7.5", "803a563113981aaac202a1dbd39771562d0ad31004ddbfc9b5090bdcd5605277", [:mix], [], "hexpm", "193b28a9b12891cae351d81a0cead165ffe67df1b73fe5866d10629f4faefb12"},
  "vix": {:hex, :vix, "0.38.0", "77529ee4f6ced339c3d5f90a9eacf306f5b7109d3d1b5e3ef391a984ad404f75", [:make, :mix], [{:cc_precompiler, "~> 0.1.4 or ~> 0.2", [hex: :cc_precompiler, repo: "hexpm", optional: false]}, {:elixir_make, "~> 0.7.3 or ~> 0.8", [hex: :elixir_make, repo: "hexpm", optional: false]}, {:kino, "~> 0.7", [hex: :kino, repo: "hexpm", optional: true]}], "hexpm", "dca58f654922fa678d5df8e028317483d9c0f8acb2e2714076a8468695687aa7"},
}

mix deps.tree

> mix deps.tree
deps_test
├── image ~> 0.43 (Hex package)
│   ├── phoenix_html ~> 2.1 or ~> 3.2 or ~> 4.0 (Hex package)
│   ├── sweet_xml ~> 0.7 (Hex package)
│   └── vix ~> 0.33 (Hex package)
│       ├── cc_precompiler ~> 0.1.4 or ~> 0.2 (Hex package)
│       │   └── elixir_make ~> 0.7 (Hex package)
│       └── elixir_make ~> 0.7.3 or ~> 0.8 (Hex package)
└── lazy_html >= 0.0.0 (Hex package)
    ├── cc_precompiler ~> 0.1 (Hex package)
    ├── elixir_make ~> 0.9.0 (Hex package)
    └── fine ~> 0.1.0 (Hex package)

When i remove lazy_html, run mix deps.get and put it back in i get:

> mix deps.get
Resolving Hex dependencies...
Resolution completed in 0.065s
Because image >= 0.64.0 depends on fine 0.1.4 and "the lock" specifies fine 0.1.5, image >= 0.64.0 is incompatible with the lock.
And because "the lock" specifies image 0.64.0, no version of the lock is allowed.
So, because your app depends on the lock, version solving failed.
** (Mix) Hex dependency resolution failed

[kipcole9]

Nice spelunking. fine is pinned because exla 0.11.0 can’t compile with fine 0.1.5. There is an open discussion on the exla GitHub about this.

[kevinschweikert]

I don't want to focus on image here but in general that i would've loved an info from the deps resolver like:

can't update image to 0.64.0 because it depends on fine 0.1.4 and your lock file specifies fine 0.1.5

[josevalim]

Can you please move this issue to Hex? Please do a search there, as I believe it has been reported. I'd say the issue is in mix hex.outdated saying you can update while you cannot.

I don't want to focus on image here but in general that i would've loved an info from the deps resolver like:

It is very hard to say that. There may be 100 versions after 0.63. So to which one do we report the failed update about? The latest? What if the latest is 3.x? The latest that matches? What if we could upgrade to 0.63.1 though but not 0.64?

You will get this error message if you explicitly force image to be 0.64.0 in your mix.exs. But it is hard to have the error message at the same time we are searching for a possible answer.

[ericmj]

If you wan't the solver to say why it cannot update to a version you expect, the best thing is to force the update by setting this in your mix.exs:

{:image, "0.64.0"}

[josevalim]

And for what is worth, the docs for mix hex.outdatedalready says this:

Note that when this task determines if a package is updatable it only looks at
the project's current set of dependency requirements and what version they are
locked to. When mix deps.update is called multiple packages may be updated that
in turn update their own dependencies, which may cause the package you want to
update to not be able to update.

Perhaps we need to add this:

If you want to force a dependency to be updated to a given version, you can directly
update it in your mix.exs.

[kevinschweikert]

Duplicate of hexpm/hex#1074

I will move any further suggestions to the hex repo. Sorry for causing the trouble y'all!