How to manage conflicts with duplicate dependencies (the same module gets defined twice)

I’ve started a question on SO about my problem so I won’t go into much details here. In general I have trouble with the same module getting defined twice in dependent projects.
Please check it out:

For me it seems like a bigger issue with dependencies. Is there some way I could solve this from my code side (like not modifying dependencies)?
Also I am able to modify one of them (not Ecto obviously) but what would be the best practice here? To avoid having the same module defined twice


1 Like

Hey guys, I’ve started bounty on this question as I think it really should get more love and deserves some ideas how to solve the problem with implementing Protocols for the same other types in different projects. Please give it some thoughts! :slight_smile:

1 Like

I have been hesitant to write an answer on your StackOverflow question because I do not have a solution for you.

The problem here, is that protocol implementations are internally placed in the module ‘Protocolname.ImplementationStructName’. When there are two implementations of the same protocol for the same data structure, this module already exists because of the other implementation.

The only ‘solution’ to this problem would be to split the protocol implementation off into its own dependency, and have both conflicting dependencies (Ecto and Gold) both use that as dependency.

For an end user that would not be able to influence the canonical version of these dependencies, the only solution would be to manually change one of the dependencies to remove.

A similar problem is described here:

It is impossible to use two applications/modules/dependencies that define/use the same name. This is intrinsic to the BEAM, as the name of a module is 1:1 with its identity.

I guess the only solution is to change one of deps ( Gold) or to change the json library in Gold. Also remove mix.lock and re-run mix deps.get

I think the most reasonable would be to convince guys from Ecto to put the implementation of this protocol into another simple dependency (all in all this implementation is modifying two outside dependencies - Decimal and Poison, it doesn’t have anything to do with Ecto at all). This way also Gold should dependend on this new dependency and everything would work, but I guess it wouldn’t be easy to convince guys from Ecto to do that… Maybe later I’ll open this as a suggestion at their google groups :wink: