tschnibo
Dependencies: Version incompatibility - What is the way to go?
Hey 
Just spent a day on finding out how to handle dependency problems when I need two different versions of one package. I am aware that there is always the option to create my own package.
Nevertheless, what I ended up doing was:
- forking the dependency which I need two versions of
- branching it
- rename the module using: GitHub - MainShayne233/rename: Rename your Elixir apps
- commit to the new branch
- in mix.exs add dependency from my fork with the specific branch and the original / different version separately
I guess for most people this is not really a challenge… first timers are always harder. Nevertheless I wanted to ask if there is a better way. (From the other entries here I don’t think so).
I don’t really like that I end up having a forked version without an other reason besides the renaming.
Is this such a rare case that one has/wants to do so?
Could one write maybe a @before_compile Macro or something similar in order to automatically rename some dependencies or keeping them “private” respectively?
Maybe based on an “alias” or “namespace” tag in the mix.exs file.
My guess is that this would lead to more complexity and therefore the “forking” approach is considered better. And I have no clue how this would work, just out of curiosity.
Cheers
Most Liked
tschnibo
fair I use mssqlex in the “original” version which comes with db_connection v1.1 for sap-hana
(just because it works with only minor changes) and then the mssqlex_v3 package which depends on db_connection v2.0 for Microsoft-SQL… I only read on the DB’s. Internally I use mongdb at the moment.
hubertlepicki
Right. So there’s one more option but I am not sure if it’s any more less terrible than what you figured out. Maybe, maybe not. You could set up non-homogenous Erlang/Elixir cluster where one node has an app loaded on it that talks to sap-hana, and other node has deployed app that talks to microsoft-sql…
Again, I am not saying it’s a good solution as it’s got it’s own set of problems in set up like that, starting with way more complicated deployment scenario, but it would be an alternative to what you do.
tschnibo
Thank you for thinking through and for this idea!
Actually I might even sometimes have thought about something in this direction. But at the moment this would be “over my head” and maybe as you said complicated in another way. Especially for developing, I would need to run one app separately adding sort of an “API-Layer”. If I understand this correctly. Then again I would learn about nodes… 
I also had a look at umbrella projects, but they are explicitly no suited for that problem.
So the forks are maybe really “the way to go”. What I was thinking: could one write an slightly adapted compiler / compiler plugin which takes a mix.exs or config file entry and prepends / renames specific module names accordingly? I mean I just did the whole forking stuff, no real need right now. I am more just thinking if there could be a simple solution. The larger the ecosystem gets, the more such “dependency problems” can occur I assume. What strikes me is on one hand, that the problem can be solved by renaming a package and on the other hand that it is solved that way. But of course I see that every added complexity to core functions as compilation do make the whole thing more complicated…
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers. By developers, for developers.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"