That's where I was suggesting something on the deps line that could be
inserted into the dependency's spec in mix.exs, like:
{:included_thing, "~> 1.2.3", xref: [exclude: [Core.Repo]]},
Where the xref is already a thing in a projects mix.exs for this very
problem.
To better explain.
Project-A defines module "MyProjectNarf", and sets an application config
`config :narf, external_module: MyProjectNarf`
Project-A brings in Dependency-B, which has an
Application.compile_env(:narf, :external_module)
Right now when Dependency-B is compiled, it throws this warning.
If I add to Dependency-B's project spec `xref: [exclude:
[MyProjectNarf]]` then the warning doesn't happen.
But this isn't workable because MyProjectNarf is meant to be the
variable that can change depending on the outer project importing the
dependency.
Yet if I could inject it from Project-A's spec where it imports the
dependency...
-Brandon
On 3/10/23 7:16 PM, Zach Daniel 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
<mailto: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/01e56de8-2cea-57e9-8025-19c6acea83d5%40cold.org.
