The module `FunWithFlags.Supervisor` was given as a child to a supervisor but it does not exist

[RealVidy]

I run FunWithFlags with runtime: false in my mix.exs so I can start it manually in my supervision tree because I use Phoenix.PubSub.

I have added FunWithFlags.Supervisor to my supervision tree and it works just fine in dev. In prod however, I get The module FunWithFlags.Supervisor was given as a child to a supervisor but it does not exist and I am not sure why.

I am on version 1.8.1 of the library and I use fun_with_flags_ui 0.8 which is also configured with runtime: false.

What might be the issue?

[tompave]

Thank you for using the library and for reporting the issue.

That sounds odd. Have you tried to delete and recompile all build artifacts? Also, what do you mean by "dev" and "prod"? Would that be Mix.env() or are you using a release?

[tompave]

Also, does it still happen if you choose the other option outlined in the readme? https://github.com/tompave/fun_with_flags#application-start-behaviour

[RealVidy]

I did recompile everything at the time, which didn't help, and I do use releases so that's what I meant by dev vs prod. Sorry I wasn't clear about that, I didn't realize using releases would impact the way dependencies are included in the app.

I found a way to make it work, but there were two issues I had to fix and one of them is a bit of a hack.

First, the included_application option described in the doc was indeed the way to go for me:

included_applications: [<other_apps>,  :fun_with_flags]

:fun_with_flags_ui should not be in there though, otherwise It fails.

The other issue I had was that when :fun_with_flags_ui was in my deps, it would trigger this error: (Mix) :fun_with_flags is listed both as a regular application and as an included application.

I understood it to mean that :fun_with_flags_ui adds :fun_with_flags to :applications on its own so I forked fun_with_flags_ui and changed the fun_with_flags dependency to {:fun_with_flags, "~> 1.8", runtime: false}. That's the hack I was talking about.

Now it all works great with a prod release but I'd be happy to help find a better way to fix this issue. Let me know if I can help :)

Thanks for your help!

[tompave]

It's interesting that you need to add runtime: false to the Mix deps of the UI package, using a fork. 🤔

Have you tried to define it in your application as, without using the fork:

{:fun_with_flags_ui, "~> 0.8", runtime: false}

?

[RealVidy]

I did try most possible combinations and I believe this one failed with an error akin to FunWithFlags.UI.Router module could not be found. For some reason, runtime: false seems to remove the dependency from my build entirely 🤷 .

I cannot really test this again because the only way I have found to reproduce is to deploy my code, which would break prod :/

[tompave]

Ok, thank you.

[dhaspden]

I had this exact same issue and we were able to fix it by adding the application to the release. So essentially what we did was:

          fun_with_flags: :load,
          fun_with_flags_ui: :load

In releases/0 within mix.exs. I've come to learn that runtime: false actually makes it so that the dependency is not included in the release by default so you need to force it to be included by doing that. No fork necessary. Might be worth adding that to the docs though.

[tompave]

I see, thank you @dhaspden. I would welcome PRs that update the instructions in the README.md to clarify how to configure this correctly in releases. I suppose we can also add a wiki page, if it ends up being too long.

[jmillxyz]

@dhaspden would you mind elaborating on your solution? I'm running into this problem but I'm not familiar with releases/0, and my search of the docs hasn't helped thus far. I'm using :fun_with_flags and :fun_with_flags_ui in a Phoenix app, built with mix release. I'd prefer to not fork deps if possible!

Here's what I've tried:

Attempt 1: runtime: false

mix.exs

{:fun_with_flags, "~> 1.8.1", runtime: false},
{:fun_with_flags_ui, "~> 0.8", runtime: false},

application.ex

children = [
  ...
  FunWithFlags.Supervisor
]

result

Fails at runtime:

"The module FunWithFlags.Supervisor was given as a child to a supervisor but it does not exist."

Attempt 2: app: false

mix.exs

{:fun_with_flags, "~> 1.8.1", app: false},
{:fun_with_flags_ui, "~> 0.8", app: false},

application.ex

children = [
  ...
  FunWithFlags.Supervisor
]

result

VSCode complains that my deps are out of date, so I run mix deps.get and see

Dependencies have diverged:
* fun_with_flags (Hex package)
  the dependency fun_with_flags in mix.exs is overriding a child dependency:

  > In mix.exs:
    {:fun_with_flags, "~> 1.8.1", [env: :prod, repo: "hexpm", hex: "fun_with_flags", app: false]}

  > In deps/fun_with_flags_ui/mix.exs:
    {:fun_with_flags, "~> 1.8", [env: :prod, hex: "fun_with_flags", repo: "hexpm", optional: false]}

  Ensure they match or specify one of the above in your deps and set "override: true"
** (Mix) Can't continue due to errors on dependencies

Attempt 3: included applications

mix.exs

def application do
  [
    mod: {MyApp.Application, []},
    included_applications: [:fun_with_flags, :fun_with_flags_ui],
    extra_applications: [...etc]
  ]
end

defp deps do
  [
    ...
    {:fun_with_flags, "~> 1.8.1"},
    {:fun_with_flags_ui, "~> 0.8"},
  ]
end

application.ex

children = [
  ...
  FunWithFlags.Supervisor
]

result

During mix release I see:

Step 24/38 : RUN mix release
[1690](https://github.com/viabeacon/beacon/runs/7545704718?check_suite_focus=true#step:13:1691)
 ---> Running in 71cb18ab014a
[1691](https://github.com/viabeacon/beacon/runs/7545704718?check_suite_focus=true#step:13:1692)
** (Mix) :fun_with_flags is listed both as a regular application and as an included application

[zaid]

@jmillxyz I got it working by marking the two dependencies with runtime: false (attempt 1 in your example) and making the following changes to the releases function in mix.exs:

defp releases() do
  [
    my_app: [
      applications: [
        fun_with_flags: :load,
        fun_with_flags_ui: :load
      ]
   ]
]
end

I'll create a pull request to update the documentation shortly.

[tompave]

Thank you for everyone's efforts in investigating and documenting this.

I would appreciate it if other people who've come across this problem could have a look at the documentation PR and express feedback.