Thanks! I ask because this is one of those things I thought I knew the answer to then 30 mins later I still going 
sodapopcan
0
feld
This one works, but not if the list you’re passing is a module attribute like:
@mods [Foo]
use MultiUse, @mods
In that case it errors like this:
** (Protocol.UndefinedError) protocol Enumerable not implemented for {:@, [line: 12, column: 28], [{:mods, [line: 12, column: 29], nil}]} of type Tuple
0
sodapopcan
That’s why he set the module attribute within the macro.
The problem is that use, as well as import and alias, are scoped to the block they are called in, so you have to get around that somehow and it’s a little tricky.
For example:
defmodule Foo do
if true do
import String
capitalize("foo") # all good!
end
capitalize("foo") # Error: `capitalize` doesn't exists
end
2
feld
But I need the module attribute in the other module. Let me just lay my cards out here, this is for Telemetry/Logging. The goal is to have a telemetry module that receives events and turns them into log messages. I don’t want to end up with a 2000 line file or be forced to have multiple modules duplicating the same code
So in start/2 of application.ex:
# register the handlers
Project.Telemetry.Logs.setup()
and then in the module that wires everything up:
defmodule Project.Telemetry.Logs do
@moduledoc "Transforms telemetry events to logs"
require Logger
@loggers [
Project.Telemetry.Logs.FileStore,
Project.Telemetry.Logs.Oban,
Project.Telemetry.Logs.Tesla
]
# I need to have a use here that can "use" each of those @loggers modules
# which will inject their handle_event/4 functions into this file
def setup do
events =
Enum.reduce(@loggers, [], fn logger, acc ->
acc ++ logger.events()
end)
Enum.each(events, fn event ->
:telemetry.attach({__MODULE__, event}, event, &__MODULE__.handle_event/4, [])
end)
end
# Catchall
def handle_event(event, measurements, metadata, _) do
Logger.error(fn ->
"Unhandled telemetry event #{inspect(event)} with measurements #{inspect(measurements)} and metadata #{inspect(metadata)}"
end)
:ok
end
end
example logger module:
defmodule Project.Telemetry.Logs.Oban do
@moduledoc false
@events [
[:oban, :job, :exception]
]
def events(), do: @events
defmacro __using__(_opts) do
quote do
def handle_event([:oban, :job, :exception], _measure, meta, _) do
Logger.error(fn ->
"[Oban] #{meta.worker} error: #{inspect(meta.error)} args: #{inspect(meta.args)}"
end)
end
end
end
end
0
sodapopcan
Zach’s solution does this, though, it just does it sneakily. You could change @using_modules to @loggers in MultiUse.__using__ then do:
def Example do
use MultiUse, [Foo]
end
and this will create a @loggers attribute will be available in Example. You could even change MutiUse to set the module name, like use MultiUse, {[Foo, Bar], set_attribute: :logger}) or something. This is why it’s tricky.
My feeling is that there is a better way to do this that still accomplishes your end goal, especially since calling use, import, alias in loops isn’t something that comes up often at all. I’ve never faced it myself in 5+ years of Elixir. I’d have to think on it myself or perhaps someone who has more experience with :telemetry can advise.
0
feld
Oh I see it now, I just needed a second cup of coffee. 
So I could make the canonical list of modules the one I pass to use MultiUse and it injects the module attribute back into the module for me to use.
I might be okay with that but it’s obscure enough that I’d have to leave breadcrumbs for other people working on this codebase 
Another thought I had this morning was to just loop through a list modules in the application.ex setup/2, perhaps read via Application.get_env, and make that the source of truth for which telemetry-derived logs are enabled.
edit: yeah, I can make it work this way by putting the use at the bottom of each module that registers for telemetry events so the catchall will still work. This way I’m not fighting with the compiler to do something it’s not meant to do.
0
feld
BartOtten
Maybe this solution was not the right one, but there might be others. Maybe we can find one in another direction?
Edit: I’m on mobile, @sodapopcan is in meeting. Frustrating hours 
1
sodapopcan
Personally, I agree that “how to call use in a loop” is “just not worth it.” There are maybe some situations in libraries where it could be? I dunno, I just wouldn’t ever suggest doing it. But I’m actually quite interested in whatever the solution to OP’s problem ends up being—that is if there is a clean way to not have to maintain two lists of the same modules. I assume this would involve registering the event handlers in a different way (but I’ve given it no thought, I’m responding here in between meetings).
0
BartOtten
I assume the modules are listed only once in a file. Why not make use of callbacks to collect event handlers and register handlers? This way the ‘use’ is ehhhh un’use’d
Example in Routex. (working on this lib at the moment, so maybe all I see is a hammer right now)
For your use case this could look like:
defmodule Processor do
ast = for module <- @modules do
apply(module, :generate_handlers, [])
ene
Module.create(MyHandlers, ast)
end
defmodule LoggerX do
def generate_handlers() do
quote do
def handle_event([:oban, :job, :exception], _measure, meta, _) do
Logger.error(fn ->
"[Oban] #{meta.worker} error: #{inspect(meta.error)} args: #{inspect(meta.args)}"
end)
end
end
end
The events to collect are missing in this example but that’s not that hard to add (but still on mobile). Does this seem a viable option for your use case?
- we could even traverse the returned AST to know all handled events.
0