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.

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.

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…