Update phoenix_ecto dep to "~> 4.0"

[scottswezey]

New phoenix 1.4 installations require phoenix_ecto ~> 4.0, which conflicts with the requirement for version ~> 3.2 in this project.

[sublimecoder]

Ah yeah I’ll get that corrected.

…

-- Jared Smith

On Nov 17, 2018, 9:34 PM -0800, Scott Swezey ***@***.***>, wrote: New phoenix 1.4 installations require phoenix_ecto ~> 4.0, which conflicts with the requirement for version ~> 3.2 in this project. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[scottswezey]

I've been going through the dependency chain to see how "easy" it will be to fix this.

1. Updating the phoenix_ecto dependency to ~> 4.0 will cause a conflict on the explicit ecto ~> 2.1 requirement.
2. Removing the explicit ecto dependency still leaves an issues with scrivener_ecto ~> 1.3.
3. Updating scrivener_ecto dep to ~> 2.0 leaves an issues with ex_queb requiring ecto ~> 2.0.
4. ex_queb appear to be a project from the original author with no updates for newer ecto versions available.

I still need to check into what the ex_queb project does and if it can be easily updated or replaced. Also, this is also all hypothetical, since I haven't started to look at updating the codebase for breaking changes in any of the above libraries.

[scottswezey]

At a first glance, the ex_queb project looks rather simple and should be easy to update for ecto 3.0. I've opened an issue on that project to see if they plan to release an update or would accept a pull request.

E-MetroTel/ex_queb#10

If the project won't update or is abandoned, it should be simple enough to fork and update.

[sublimecoder]

Sounds good, thanks for doing that.

…

-- Jared Smith

On Nov 17, 2018, 10:14 PM -0800, Scott Swezey ***@***.***>, wrote: At a first glance, the ex_queb project looks rather simple and should be easy to update for ecto 4.0. I've opened an issue on that project to see if they plan to release an update or would accept a pull request. E-MetroTel/ex_queb#10 If the project won't update or is abandoned, it should be simple enough to fork and update. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[scottswezey]

Well, I haven't heard back from the E-MetroTel team, so I went ahead and started work on supporting Ecto 3.0 and other housekeeping for the ex_queb project. It didn't seem to have a very complete set of tests, so I'm not highly confident in the update being non-breaking... especially around date/time given that Ecto has dropped support for the Ecto.Date/Time/DateTime modules in favor of the native elixir variants.

My fork is available at https://github.com/scottswezey/ex_queb

Next I'll begin attempting to integrate ex_admin into my new phoenix 1.4 project with updated dependencies. Fingers crossed it all goes well.

[sublimecoder]

Awesome appreciate it! I’ll get this updated shortly, busy with holiday this week, but hopefully Friday I’ll get this update in.

…

-- Jared Smith

On Nov 19, 2018, 10:53 PM -0800, Scott Swezey ***@***.***>, wrote: Well, I haven't heard back from the E-MetroTel team, so I went ahead and started work on supporting Ecto 3.0 and other housekeeping for the ex_queb project. It didn't seem to have a very complete set of tests, so I'm not highly confident in the update being non-breaking... especially around date/time given that Ecto has dropped support for the Ecto.Date/Time/DateTime modules in favor of the native elixir variants. My fork is available at https://github.com/scottswezey/ex_queb Next I'll begin attempting to integrate ex_admin into my new phoenix 1.4 project with updated dependencies. Fingers crossed it all goes well. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[scottswezey]

So far, the update to phoenix_ecto isn't going well. I've managed to break many parts of the codebase, I've had to comment out all kinds of Ecto datetime related code and haven't had time to look if that breaks more things. At least I have the test suite running again.

I expect to have some free time, so I'll keep plugging away and hopefully have a PR, or at least a branch to review. In any case: Consider this all highly experimental.

[sublimecoder]

@scottswezey Any further developments on the ecto upgrade?

[scottswezey]

Unfortunately not, I got busy and haven't had much time to keep digging into it. I'm still not confident in my updates to ex_queb, nor have I heard back from them about accepting a PR or working on updates. I'm thinking it will need to be forked and replaced.

Hopefully I'll have a better testing project up and running by the end of this week and can run my updated ex_admin code against it so I'm not relying completely on the test suite.

[sublimecoder]

Sounds good. Thanks again. Let me know if there is anything I can do to assist.

…

-- Jared Smith

On Nov 28, 2018, 10:28 PM -0800, Scott Swezey ***@***.***>, wrote: Unfortunately not, I got busy and haven't had much time to keep digging into it. I'm still not confident in my updates to ex_queb, nor have I heard back from them about accepting a PR or working on updates. I'm thinking it will need to be forked and replaced. Hopefully I'll have a better testing project up and running by the end of this week and can run my updated ex_admin code against it so I'm not relying completely on the test suite. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iwarshak]

@scottswezey did you ever have any luck with this?

[scottswezey]

@iwarshak Unfortunately, the short answer is no.

I spent a weekend working on it December and never managed to get everything working correctly. Then the holidays and my day job have kept me busy since. I’ll try to look through my work later tonight and see if any of it is useful to share, but my recollection is that it’s all a giant mess.

[iwarshak]

I am using exadmin on several projects and would like to invest some time to get exadmin working for phoenix 1.4. This fork seems to be the best place to direct efforts.

Do either of you have recommendations on what still needs work?

[sublimecoder]

It currently works with Phoenix 1.4 I'm using it on two projects right now. So if you swap to using master for this fork it should work. If you run into any issues let me know and I can try to help resolve them.

[iwarshak]

@sublimecoder oh really? I had tried but ran into:

Failed to use "phoenix_ecto" (version 4.0.0) because
  deps/ex_admin/mix.exs requires ~> 3.2
  mix.lock specifies 4.0.0

What version of phoenix_ecto are you using?

[sublimecoder]

Phoenix_ecto 3.3, 4.0 has issues with some of the dependencies in ex_admin. However, the core Phoenix 1.4 can be used and I have been using Phoenix 1.4 and phoenix_ecto 3.3 for a considerable chunk of time now and no major issues. @scottswezey was working on some of the updates to the other dependencies that would be required to make the jump to phoenix_ecto 4.0. I'm not sure where those updates are at and it may be better to just start fresh at this point.

If you want to work on trying to update to phoenix ecto 4.0. I welcome any PRs you'd like to submit. I'm going to have some more free time after April 1st so I plan to work on that part if we don't have it solved by then.

[iwarshak]

For reference, this set of deps got me up and running

  defp deps do
    [
      {:phoenix, "~> 1.4.1"},
      {:phoenix_pubsub, "~> 1.1"},
      # {:phoenix_ecto, "~> 4.0"}, # was ~> 4.0
      {:phoenix_ecto, "~> 3.3.0"}, # was ~> 4.0
      # {:ecto_sql, "~> 3.0"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_html, "~> 2.11"},
      {:phoenix_live_reload, "~> 1.2", only: :dev},
      {:gettext, "~> 0.11"},
      {:jason, "~> 1.0"},
      {:plug_cowboy, "~> 2.0"},
      {:ex_admin, github: "sublimecoder/ex_admin"}
    ]
  end

[iwarshak]

This can probably be closed. #43 handles this now