Conflicting dependency versions

[goertzenator]

I have an app that depends on cowboy-2.2.2, but also depends directly on ranch because I need to do some custom SSL handling for my cowboy server. I don't specify a version on my ranch dep.

Cowboy-2.2.2 requires ranch-1.4.0, however erlang.mk quietly pulls in ranch-1.2.1 which causes cowboy to fail. My work-around is to remove the unversioned ranch dep which then causes ranch-1.4.0 to be pulled in.

Dependency version specification and conflict is a thorny issue. What happens when one app has genuine sub-dependencies on both ranch-1.2.1 and ranch-1.4.1? The Rust folks have put a lot of discussion into this problem; I don't know what the resolution is but there may be pertinent discussion there. I don't know what rebar does.

[essen]

Rebar has more or less the same approach, the first dependency wins. Which dependency is first can be different than Erlang.mk's.

The problem we have in the Erlang world is that it's not possible to run different versions of the same application side by side, so you have to make sure all dependencies are the same or compatible versions. In your case this would mean ensuring that Cowboy is listed first as a dependency before Ranch.

We can probably improve how Erlang.mk handles this kind of situation.

I would much prefer if I could rely on an external package manager if we had one. Until we do I doubt we will get to a satisfying state. We've just had a discussion at customer about how Rebar and Mix handle these cases differently which leads to problem in mixed environments for example.

So as far as Erlang.mk is concerned I would very much like to make detecting issues and debugging easier. I'm not so confident we can solve the larger issue however.

[crownedgrouse]

Only solution is to run each version in a different node, and applications talking together. If Erlang had namespaces, we could run same library in different versions and different libraries with same name at same time. Maybe some days

[essen]

There's an hex_erl project that is being worked on which will provide an Erlang interface to Hex. It will also come with dependency version resolution and I think using this will save us a lot of troubles because then for people who use only Hex dependencies they can be sure that the Hex dependencies are consistent (since Hex enforces it). This won't matter for other sources like git but it should at least be something.