What happens in an Umbrella when mix.exs have same dependencies, different versions

Hi Folks,

I have a Phoenix umbrella project with 4 applications within it. Three out of the 4 applications depend on elixir ~> 1.3, while one depends on ~> 1.2. What happens when this occurs? What are the problems that it can lead to? How is something like this fixed?

(Also, not to hijack my own thread but I screwed up my development machine and asdf stopped working, so not only do my apps depend on different version of Elixir, but I also have elixir 1.4.4 installed, which none of the apps depend on).

1 Like

Merging these two constraints is relatively simple (~> 1.3 is equivalent to >= 1.3 && <2.0; ~> 1.2 is equivalent to >= 1.2 && < 2.0) and will therefore result in ~> 1.3.

4 Likes

Oh wow. This is really awesome thank you.

The problem was that I did not know / understand what the “~>” meant. Now I can see how all these constraints are solved without conflict.

Thank you very much Nobbz.

To give some extra clarification: Version lookup using ~> is based on the Semantic Versioning Principle. It will match all versions starting with the one you specified, that are greater-or-equal in the last digit.

So 1.3 will match 1.3 up to but not including 2.0, so it will match 1.3.1, 1.4, 1.4.5, 1.99999999999999, but not 2.0.1.
1.2.4 will match 1.2.4 up to but not including 1.3 in exactly the same way, et cetera.

Note that release-candidate versions, (like 1.2-rc0 are not considered by the upgrading algorithm, as they are not taken to be ‘official, stable’ versions).

Semantic Versioning, and by extension using ~> to specify dependencies, is very useful to ensure that your application’s dependencies have the latest bugfixes, but do not break because of backwards-incompatible dependency versions.

1 Like

So how does one resolve a dependency conflict with more distance between dependency versions ?

Umbrella/AppA has deps {:poison, “~> 3.1”}
Umbrella/AppB has deps {:poison, “~> 4.0.1”}

AppA needs to be tested against a 4.0.x poison and code needs to be fixed to work with the newer version.

Hmm… So there’s no way that two sub-apps n an umbrella can have the same dependency with independent versioning. That’s what I gathered from Elixir docs. Thanks for confirming this (so quickly)

Ideally, I would have expected Umbrella Apps to work like this:
The root level mix.exs mentions shared global dependencies and the sub-app level mix.exs files should override any inherited dependencies.

The BEAM does not allow for loading different applications with the same name. So there can not be an independant resolution of dependencies.

2 Likes

OK got it, Thanks. So the quick and dirty fix would be to rename one of the dependency apps. I think someone mentioned this elsewhere on this forum.

Thats probably more work than just fixing the app that currently requires the old library, as you also need to rename all related module names and please do not ask me about any dependencies that rely on poison and therefore might even use the wrong one and cause undefined bahevior, so you need to fix them up as well…

1 Like