Distillery build error: Multiply defined module: 'Elixir.Collectable.Ecto.Adapters.SQL.Stream'

Trying to build a Phoenix 1.4 application via Distillery, and hitting this error:

==> Release failed with multiple errors:
    Multiply defined module: 'Elixir.Collectable.Ecto.Adapters.SQL.Stream'

I’ll note that this application is upgraded from Phoenix 1.3.4, and I did clean all the Elixir and Node deps and rebuild them prior to this run.

Google doesn’t seem to be much help with that error, my understanding is that it means the module is defined multiple times through more than 1 dependency. I don’t really know how to go about debugging/solving that issue though…

The verbose logs from the Distillery run are available here under the ‘Details’ of that post: https://github.com/bitwalker/distillery/issues/627#issuecomment-455009534

Here’s my entire mix.exs if that helps any…

defmodule Poof.Mixfile do
  use Mix.Project

  def project do
    [
      app: :poof,
      version: "1.2.4+001",
      elixir: "~> 1.7",
      elixirc_paths: elixirc_paths(Mix.env),
      compilers: [:phoenix, :gettext] ++ Mix.compilers,
      start_permanent: Mix.env == :prod,
      aliases: aliases(),
      deps: deps()
    ]
  end

  # Configuration for the OTP application.
  #
  # Type `mix help compile.app` for more information.
  def application do
    [
      mod: {Poof.Application, []},
      extra_applications: [:asn1, :logger, :runtime_tools],
    ]
  end

  # Specifies which paths to compile per environment.
  defp elixirc_paths(:test), do: ["lib", "test/support"]
  defp elixirc_paths(_),     do: ["lib"]

  # Specifies your project dependencies.
  #
  # Type `mix help deps` for examples and options.
  defp deps do
    [
      {:phoenix, "~> 1.4.0"},
      {:phoenix_pubsub, "~> 1.0"},
      {:ecto_sql, "~> 3.0"},
      {:phoenix_ecto, "~> 4.0"},
      {:postgrex, "~> 0.14"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:plug_cowboy, "~> 2.0"},
      {:timex, "~> 3.4.0"},
      {:uuid, "~> 1.1"},
      {:basic_auth, "~> 2.2"},
      {:dynamic_server_manager, "~> 0.0.10"},
      {:distillery, "~> 2.0"},
      {:swoosh, "~> 0.13"},
      {:tesla, "~> 1.2.0"},
      {:jason, "~> 1.1.0"},
      {:mox, "~> 0.3", only: :test},
    ]
  end

  # Aliases are shortcuts or tasks specific to the current project.
  # For example, to create, migrate and run the seeds file at once:
  #
  #     $ mix ecto.setup
  #
  # See the documentation for `Mix` for more info on aliases.
  defp aliases do
    [
      "ecto.setup": ["ecto.create", "ecto.migrate"],
      "ecto.clean": ["ecto.drop", "ecto.setup"],
      "ecto.seed": ["run priv/repo/seeds.exs"],
      "ecto.reset": ["ecto.clean", "ecto.seed"],
      test: ["ecto.create --quiet", "ecto.migrate", "test"]
    ]
  end
end

As a first test, have you wiped your _build directory to make sure no lingering modules between dependency updates or so? Better yet have you tried fresh cloning into a new directory and building it there?

EDIT: Yeah the only place I’m finding a Collectable implementation for Sql’s Stream is at:

deps/ecto_sql/lib/ecto/adapters/sql/stream.ex:defimpl Collectable, for: Stream do

So the deps themselves look good. I’d definitely recommend trying to git clone it into a fresh directory and try it there next. Otherwise we might need to look at the project (which one of us can do in private if it’s not a public project if you want).

Ah, I had done “mix deps.clean --all” and “rm -rf assets/node_modules”, but not “rm -rf assets/_build”.

Removing _build and re-running the build process seems to have fixed the issue – good to know for the future!

Followup question: IIRC, Distillery uses stuff in _build when building upgrade releases, so if wiping _build becomes necessary, I guess that clobbers the option to do a hot upgrade?

1 Like

Wiping _build is something that shouldn’t need to be done, but there is still a bug or two in mix left where it is required. I’ve especially noticed it on rare dependency updates like you’ve experienced it here too.

You can actually backup the hot code reloading information if you so wish by backing up the _build/prod/rel/<project-name>/releases directory and restoring it. That directory holds the past release information. You can also copy it back in from where-ever you copied your release to, to restore it. :slight_smile:

2 Likes