1.13 umbrella project dependency warnings

Questions / Help
,
1

I’m migrating from elixir 1.10.4 to 1.13.4, and I get lots of these warnings:

This happens for a lot of different dependencies, Poison is just an example.

I have an umbrella project structure. At this stage elixir is compiling apps/common.

In the top-level mix.exs:

defmodule Toplevel.Mixfile do
use Mix.Project

def project do
  [ apps_path: "apps",
    build_embedded: Mix.env == :prod,
    start_permanent: Mix.env == :prod,
    deps: deps(),
    releases: releases() ]
end

def deps do
  [ {:syn,        path: "deps/syn",        override: true},
    {:sweet_xml,  path: "deps/sweet_xml",  override: true},
    {:poison,     path: "deps/poison",     override: true},

So it is mentioned in deps on top level. And in the apps/common/mix.exs:

defmodule Common.Mixfile do
  use Mix.Project

  def project do
    [app: :common,
     version: "0.1.0",
     build_path: "../../_build",
     config_path: "../../config/config.exs",
     deps_path: "../../deps",
     lockfile: "../../mix.lock",
     elixir: "~> 1.10",
     build_embedded: Mix.env == :prod,
     start_permanent: Mix.env == :prod,
     compilers: compilers(),
     elixirc_options: [ warnings_as_errors: true, long_compilation_threshold: 30 ],
     deps: deps()]
  end

[...]

  def deps do
    base_path = case Mix.env do
      :test -> "../.."
      _     -> "."
    end

    [{:syn,        path: "#{base_path}/deps/syn",        override: true},
     {:sweet_xml,  path: "#{base_path}/deps/sweet_xml",  override: true},
     {:poison,     path: "#{base_path}/deps/poison",     override: true},
     {:exoml,      path: "#{base_path}/deps/exoml",      override: true}]
  end

So it is mentioned in def deps in both mix.exs files - top level and in the application under the umbrella.

I still get the warning in spite of it being present there. Why?

Thank you.

2

One thing I’ve seen cause a similar symptom is having an application function like this in one of the mix.exs:

def application do
  [
    mod: {SomeApp.Application, []},
    applications: [:credo, :logger, :runtime_tools]
  ]
end

Having applications (instead of or in addition to extra_applications) short-circuits the automatic dependency detection that normally fills applications in by traversing deps.

1 Like
3

Really?

I grepped and I see I do that:

  def application do
    [applications: [:logger]]
  end

So could that be the cause?

4

I don’t think top level dependencies count here. They’re really only useful for development dependencies. You’d likely want to move poison to be an explicit dependency of any of the umbrella apps, which use it.

5

I have changed applications: [:logger] to [ extra_applications: [:logger] after reading up on it and now it seems to work (better). I’m trying to see it will correctly resolve also for more complicated cases, but I’m hopeful. :slight_smile:

Thanks!