Dependency conflicts when using Timex with Ejabberd

[arenrover0]

Issue Description

I am encountering dependency conflicts in my Phoenix application that utilizes Ejabberd as a dependency. The issue arises when trying to use Timex for working with time. I receive the following error message:

Because the lock depends on xmpp 1.8.1 which depends on idna 6.0.0, the lock requires idna 6.0.0. And because hackney >= 1.17.0 depends on idna ~> 6.1.0, the lock is incompatible with hackney >= 1.17.0. And because tzdata >= 1.1.0 depends on hackney ~> 1.17, the lock is incompatible with tzdata >= 1.1.0. And because timex >= 3.7.8 depends on tzdata ~> 1.1, the lock is incompatible with timex >= 3.7.8. And because your app depends on the lock, timex >= 3.7.8 is forbidden. So, because your app depends on timex ~> 3.7.8, version solving failed.

Additionally, when attempting to use Timex version 3.7.7, I encounter the following error:

[error] GenServer :tzdata_release_updater terminating ** (UndefinedFunctionError) function :ssl.cipher_suites/0 is undefined or private (ssl 10.8.7) :ssl.cipher_suites() (hackney 1.15.2) /home/project/deps/hackney/src/hackney_ssl.erl:77: :hackney_ssl.ciphers/0 (hackney 1.15.2) /home/project/deps/hackney/src/hackney_ssl.erl:69: :hackney_ssl.connect/4 (hackney 1.15.2) /home/project/deps/hackney/src/hackney_connect.erl:277: :hackney_connect.do_connect/5 (hackney 1.15.2) /home/project/deps/hackney/src/hackney_connect.erl:47: :hackney_connect.connect/5 (hackney 1.15.2) /home/project/deps/hackney/src/hackney.erl:333: :hackney.request/5 (tzdata 1.0.5) lib/tzdata/http_client/hackney.ex:17: Tzdata.HTTPClient.Hackney.head/3 (tzdata 1.0.5) lib/tzdata/data_loader.ex:46: Tzdata.DataLoader.last_modified_of_latest_available/1 Last message: :check_if_time_to_update

Environment:

• Erlang/OTP version: 25 [erts-13.2.2.4]
• Elixir version: 1.14.4
• Phoenix version: 1.7.2
• Ejabberd version: 24.2
• Timex version: 3.7.7, >= 3.7.8

Attempts to Solve:

In an effort to resolve the dependency conflict, I explored alternative libraries such as calendar. Unfortunately, this library also relies on tzdata

Resolution Suggestion:

Given the dependency conflicts, one possible resolution could be to update the Ejabberd dependency to a version that is compatible with the other dependencies, particularly idna. This may involve checking for newer versions of Ejabberd that have resolved these compatibility issues.

Alternatively, I'm open to suggestions from the community on how to resolve these dependency conflicts in a more effective manner.

Appreciation:

Before closing, I'd like to express my gratitude to the Ejabberd development team for their magnificent product and the hard work they've put into it. Thank you for providing such a valuable tool to the community.

Looking forward to your guidance and suggestions on resolving this issue.

[badlop]

Here is a draft patch:

From 758cb072957f6825074ea0b7ce494a54f52330bb Mon Sep 17 00:00:00 2001
From: Badlop <badlop@process-one.net>
Date: Fri, 5 Apr 2024 12:56:21 +0200
Subject: [PATCH 1/2] Add support in rebar.config to define vague dependency
 version

Instead of adding another element to the tuple, let's reuse the second
element, which was used only by rebar2, and always has ".*" as value.
---
 rebar.config.script | 33 +++++++++++++++++++++++++--------
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/rebar.config.script b/rebar.config.script
index 7d7fa864c..3634763e8 100644
--- a/rebar.config.script
+++ b/rebar.config.script
@@ -219,20 +219,35 @@ AppendList2 = fun(Append) ->
 		      end
 	      end,
 
+% Convert our rich deps syntax to rebar2 format:
+% https://github.com/rebar/rebar/wiki/Dependency-management
+Rebar2DepsFilter =
+fun(DepsList, GitOnlyDeps) ->
+	lists:map(fun({DepName, _HexVersion, Source}) ->
+	              {DepName, ".*", Source}
+		  end, DepsList)
+end,
+
+% Convert our rich deps syntax to rebar3 version definition format:
+% https://rebar3.org/docs/configuration/dependencies/#dependency-version-handling
+% https://hexdocs.pm/elixir/Version.html
 Rebar3DepsFilter =
 fun(DepsList, GitOnlyDeps) ->
-	lists:map(fun({DepName, _, {git, _, {tag, Version}}} = Dep) ->
-			  case lists:member(DepName, GitOnlyDeps) of
-			      true ->
-				  Dep;
-			      _ ->
-				  {DepName, Version}
+	lists:map(fun({DepName, HexVersion, {git, _, {tag, GitVersion}} = Source}) ->
+			  case {lists:member(DepName, GitOnlyDeps), HexVersion == ".*"} of
+                              {true, _} ->
+				  {DepName, ".*", Source};
+                              {false, true} ->
+                                  {DepName, GitVersion};
+                              {false, false} ->
+                                  {DepName, HexVersion}
                           end;
-		     (Dep) ->
-			  Dep
+		     ({DepName, _HexVersion, Source}) ->
+	              {DepName, ".*", Source}
 		  end, DepsList)
 end,
 
+
 DepAlts = fun("esip") -> ["esip", "p1_sip"];
 	     ("xmpp") -> ["xmpp", "p1_xmpp"];
 	     ("fast_xml") -> ["fast_xml", "p1_xml"];
@@ -423,6 +438,8 @@ Rules = [
 	  ProcessRelx, [], []},
 	 {[deps], [floating_deps], true,
 	  ProcessFloatingDeps, [], []},
+	 {[deps], [gitonly_deps], (not IsRebar3),
+	  Rebar2DepsFilter, [], []},
 	 {[deps], [gitonly_deps], IsRebar3,
 	  Rebar3DepsFilter, [], []},
 	 {[deps], SystemDeps /= false,
-- 
2.43.0

With this patch, if rebar.config contains:

{fast_tls, ">= 1.1.15", {git, "https://github.com/processone/fast_tls", {tag, "1.1.10"}}},
{fast_xml, ">= 1.1", {git, "https://github.com/processone/fast_xml", {tag, "1.1.20"}}},

Rebar2 follows dumbly the git tag:

Pulling fast_tls from {git,"https://github.com/processone/fast_tls", {tag,"1.1.10"}}
Pulling fast_xml from {git,"https://github.com/processone/fast_xml", {tag,"1.1.20"}}

Rebar3 gets the latest versions from Hex:

===> Fetching fast_tls v1.1.19
===> Fetching fast_xml v1.1.51

An umbrella project that uses the mix build tool, when it downloads ejabberd, it will use rebar3 to build ejabberd.

If that patch looks good, it should be applied to ejabberd and all the ejabberd dependencies... Starting with xmpp, which is the one you are facing the problem now.

@prefiks and anyboy else with knowledge in rebar.config: what do you think about that patch. Is the feature worth improving? Do you see any problem in the feature or the patch?

[badlop]

I've updated the xmpp library in its git repository, and also ejabberd. Now it is able to download the latest or other acceptable dependency versions:

$ make
rebar3 get-deps
===> Verifying dependencies...
===> Fetching ezlib v1.0.12
===> Fetching fast_tls v1.1.19
===> Fetching fast_xml v1.1.51
===> Fetching idna v6.1.1
===> Fetching p1_utils v1.0.25
===> Fetching stringprep v1.0.29
===> Fetching unicode_util_compat v0.7.0
...