ExIcal is locked to an old version of Timex

[leesharma]

Current Behavior

ex_ical is locked on to an old release of timex ({:timex, "~> 1.0"}, they're currently at 3.x).

This means that in order to use ex_ical in a project (assuming that the project isn't using timex ~> 1.0, a developer needs to not only include an extra library/version, but they will also need to write their own adapter from the old Timex datetime formats into whatever library they're using in their application.

Desired Behavior

This library should be able to work with current DateTime libraries.

Since Date and DateTime were only just added to Elixir (end even then, they aren't a complete implementation), there are a number of libraries available (timex, calendar, good_times, etc.) Ideally, using ex_ical shouldn't lock you into having to use a specific version of a specific library–it should be able to work with a number of options. Just upgrading to timex ~> 3.0 makes the situation better, but it won't solve the full problem. I think that using an adapter pattern and letting the user specify their library/adapter is the best way to handle this.

Possible Interface

Ideally, something like the following interface would work. It should be able to handle a default case with minimal boilerplate required; common cases with a small amount of configuration; and "unsupported" cases with a bit more configuration.

Using the default datetime library (Timex, current version)

# mix.exs

def applications do
  [applications: [:timex, ...]]
end

def deps do
  [
    {:timex, "~> 3.0"},
    {:ex_ical, "~> 1.0"},
    ...
  ]
end

Using calendar, another popular DateTime library

# mix.exs

def applications do
  [applications: [:calendar, ...]]
end

def deps do
  [
    {:calendar, "~> 1.0"},
    {:ex_ical, "~> 1.0"},
    ....
  ]
end


# config/config.exs

config :ex_ical,
  datetime_library: :calendar

Using an unsupported or "bespoke" DateTime solution

# mix.exs

def applications do
  [applications: [...]]
end

def deps do
  [{:ex_ical, "~> 1.0"}, ...]
end


# config/config.exs

config :ex_ical,
  datetime_library: :bespoke_datetime,
  datetime_adapter: BespokeDateTime.Adapter  # the user writes this module

[fazibear]

It's a great idea. Didn't notices that they updating Timex so fast. Anyway I think this is a great solution. We will not depend on specific library. It will fit to any project. We can support interfaces for most popular libraries.

[leesharma]

Yay! 😄

I think that using mix config probably makes the most sense for this. Since project config supersedes app config, we could set defaults in-app and parent project would be able to override them. This setup should be pretty testable too–we can manually set the config with Application.put_env/4 and test the adapter interface against all built-in options.

For an example, Ecto uses almost the same pattern: they have Application.get_env/3 and a case statement to select the adapter class in tests (though they use env vars) and a set of functions/macros to get the class in lib (some example usage here: Ecto.Adapters.SQL, case statement in tests).

Maybe starting with a fixed set of adapters for the most common cases would be easiest (maybe the current versions on timex and calendar)? After that, the option to add custom adapters can be added.