How does `Phoenix.CodeReloader ` work? (I'm trying to do something simpler)

Phoenix Forum Questions / Help
, ,
1

The description for Phoenix.CodeReloader starts like this:

For each request, Phoenix goes through all modules and checks if any of them implement a __phoenix_recompile__?/0 function. If they do and it returns true, the module source file is touched, forcing it to be recompiled. For this functionality to work, Phoenix requires you to add the :phoenix compiler to your list of compilers: […]

Can someone explain how this works? I’m confused by:

  • Where does __phoenix_recompile__? come from?
  • What does adding :phoenix to the list of compilers do?
  • Where does the reloading of a successfully-compiled new version of a source file happen?

What I want to accomplish

To learn LiveView, I want to provide a localhost view into the runtime structure created by a set of modules. The modules have very specific constraints that mean I don’t need to care about a lot of special cases. What I have is:

  • a set of modules. Each has a single “constructor” function (all with the same name) that makes a big nested structure.
  • a genserver module that maintains a map from module name to big nested structure.

My “watcher” app is to start by loading up all the modules, populating the genserver map, and displaying pretty things in a browser interface.

When one of the module source files is (successfully) changed, I want the watcher app to:

  1. Notice that a module is out of date (probably via file_system).
  2. Delete that module from the genserver.
  3. Load the new version of the module’s code.
  4. Run the constructor function and add the new big nested structure to the genserver.

By “very specific constraints” above, I mean, for example, that there are no compile-time dependencies between these modules. There’s an extra level of indirection meaning that the Animal module does not have to be redefined when the Species module changes.

Because my case is so simple, it seems like Phoenix.CodeReloader, phoenix_live_reload, the vsn module attribute, and IEX’s r command are doing things I don’t have to do.

I’m hoping I don’t have to understand complicated cases to implement the simple case.

1 Like
2

Maybe @IvanR can help here, because he was working with the Phoenix code reloader to fix a bug I reported in his Domo library.

3

Sounds like an interesting visualization! I’m excited to hear more about it eventually.

I think you might be interested in looking at exsync which is an alternative code reloader that is built on file_system (and that I help maintain):

The code should be pretty easy to follow and it’s easy to change the code to call a function every time a module is changed.

2 Likes
4

FWIW, Phoenix.CodeReloader calls mix compile under the hood. It is not effectively compiling. The custom compiler and __phoenix_recompile__? were specific for template reloading but this feature has been moved to Mix and will be deprecated from Phoenix.

From your description, you probably want to play with the Code module in Elixir and the associated :code module in Erlang - as it seems you don’t want to compile the code but act on the code that is available/has been compiled.

1 Like
5

Thank you all. exsync is easy to understand. The trick I was missing was that Code doesn’t reveal the two functions :code.load_file and :code.load_binary. You can see how the latter is used in exsync here.

@josevalim: Would it be useful to add something like the following text at the end of the Working with files section of the Code documentation?

“The three functions above work with Elixir source. If you want to load a compiled file (typically found below the _build directory of a Mix project, with the extension .beam), see the Erlang functions :code.load_file/1 and :code.load_binary/3.”

That would have saved me from taking some unproductive paths. If so, I’ll make a PR.

3 Likes
6

Yeah, a PR is welcome!

2 Likes