Hi Austin and Zach,
For the Bamboo Phoenix case, they should declare phoenix_view as an
optional dependency. Then either conditionally compile code or use
"@compile {:no_warn_undefined, Phoenix.View}" in the relevant module. Note
Elixir v1.14 introduce a --no-optional-deps flag to help library authors
test that their projects work without optional dependencies.
Zach, if a module is configured and seen only at runtime, then no warning
is emitted. If a module is configured at compile time, then you can also
include it as part of xref. For example, imagine you have this:
config :some_dep, compile_time_module: MyApp.SomeModule
This means :some_dep can do this in its "mix.exs":
xref: [exclude: List.wrap(Application.get_env(:some_dep,
:compile_time_module))]
Or, perhaps even better, you can do this in the file that uses the compile
time attribute:
module = Application.compile_env(:some_dep, :compile_time_module)
@compile {:no_warn_undefined, module}
On Sat, Mar 11, 2023 at 3:16 AM Zach Daniel <zachary.s.dan...@gmail.com>
wrote:
> This does actually strike a chord for me and I'm realizing this is likely
> a related question or perhaps the same question in another form. Is there
> some way to define a module that a dependency can use at compile time or at
> runtime without these warnings? Like a module that you want compiled
> before a specific dependency/dependencies?
>
>
> On Fri, Mar 10, 2023 at 9:11 PM, Brandon Gillespie <bran...@cold.org>
> wrote:
>
>> On 3/10/23 3:33 PM, Austin Ziegler wrote:
>>
>>
>> 1. The warning that I think is being discussed is a compile warning
>> for the library *dependency*, not for the hosting application, which
>> matches what I have seen.
>>
>>
>> This.
>>
>>
>> I'm working on creating a focused way of reproducing it, but need some
>> time to get it all dialed in.
>>
>> Essentially though, you are right.
>>
>> What we are working on is a way to put Ecto models into a library
>> dependency that can be brought into other applications. But for this to
>> work, we have to abstract the definition of Ecto.Repo and defer it to
>> runtime. However, because dependencies are pre-compiled, you then get these
>> warnings.
>>
>> This is a use case that's very compelling, and yet it goes against how
>> things work right now with the way dependencies are, but that doesn't
>> remove the value of having something like this.
>>
>> oban is a great example.
>>
>>
>> -Brandon
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/194c5d9c-6ba3-6599-0436-caae01bec86c%40cold.org
>> <https://groups.google.com/d/msgid/elixir-lang-core/194c5d9c-6ba3-6599-0436-caae01bec86c%40cold.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/lf3c11ws.8e05e338-daf8-44e1-aca4-5e4d26f470d0%40we.are.superhuman.com
> <https://groups.google.com/d/msgid/elixir-lang-core/lf3c11ws.8e05e338-daf8-44e1-aca4-5e4d26f470d0%40we.are.superhuman.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LMCbLqAFX7sUZeDh2cTRP1wNfPdqAmKnp%2BdGezU95%3DZQ%40mail.gmail.com.
