What's the recommended process for debugging the code execution through an external package in Elixir? Is it possible to add logs there? #elixirlang
@pepicrft not sure what do you mean, but you can totally attach to a node and then observe the execution with pretty much anything, from :sys to full-blown observer.
@jonn let’s say I have an external package, and I’d like to stop the execution in a line of that package and step through the execution to see variables’ values. How would you do it?
@pepicrft it doesn't make sense in Erlang at all. Do you stop the execution of all the SMP schedulers at the same time? How do you know that other processes a process in question interacts with has deterministic state and thus you get actual signal rather than noise? Here's a small pearl that talks about it: http://blog.plataformatec.com.br/2016/05/tracing-and-observing-your-remote-node/
That said, if you are writing very simple software and depend on very simple libraries, then you need to compile your dependencies with debug symbols on (`mix deps.compile --debug-info` should suffice) and now you should be able to run debugger. Sadly, it didn't work for me when I briefly tried and the error was:
Invalid beam file or no abstract code: "/home/sweater/github/do-auth/_build/dev/lib/bamboo_smtp/ebin/Elixir.Bamboo.SMTPAdapter.beam"
I think that if you really want to spend time on conventional debugging with Elixir, you can try these steps yourself and then, if you also have the same error, ask on https://elixirforum.com/
@pepicrft oh, there's also one rather funky way! Rewrite your mix.exs to point to a dependency via filesystem. For example, a `plug` dependency shall become:
```
{:plug, path: "deps/plug"},
```
Now you can insert some hack like IEx.pry[1] straight into your dependency where you want it and `mix compile` shall automatically recompile it. Now it's suffice to run the code in `iex` and you'll get dropped into the breakpoints.
I think that this is the most Elixir way to do it, to be honest, but I'd still check if you're solving XY problem before trying. Static code analysis and tracing are way more impactful while trying to understand what's going on in a BEAM system than step-by-step debugging.
@jonn thanks for the tips John. I’m new to the ecosystem so I have a lot to learn yet. I found documentation to be quite good, but you often wonder what’s the conventional way for doing X and that’s not documented.