.iex.exs for releases?

That’s what I do, copy existing .iex.exs to a release dictionary.

I’d tend to argue against having something like .iex.exs loaded automatically in production. The remote console is quite resistant to errors and not accidentally blowing up production, but even just crashing on startup of the console and potentially blocking you from accessing the the console is something I’d try to avoid greatly. I’d rather have a function like MyApp.Ops.load_my_stuff, which does the same, but needs to be called once manually.

Yeah I have a help.ex module in my projects inside of which I have defmodule Help and a __using__ macro so that when I remote console in I can just use Help and get all the things I want.

On the other hand though, if the .iex.exs file really does cause issues you could always remote console into the server / container and delete it before remote consoling into the actual BEAM instance.

@LostKobrakai @benwilson512 Do you still use .iex.exs alongside the approaches you described here?

I am mostly wondering if there is a way to store this information in .iex.exs, so I automatically get my helpers locally, but also use them in a separate module (e.g. Help), which could be explicitly called for a release.

I realize it’s only one extra call locally as is, but wanting to see if things could be even a little more convenient

OMG sorry to necro this but a use Help is brilliant. Mostly what i want in my remote iex is imports and aliases anyways, and it’s a burden to remember each time… but “use Help” is perfect, because it’s easy to remember and only 9 keystrokes.

Hi Krut,

You can define everything in your help.ex, e.g.:

defmodule Help do
  defmacro __using__ (_opts) do
    quote do

      import Ecto.Query, warn: false
      # ...etc
      
    end
  end
end

and then in your .iex.ex simply add one line:

use Help

that way you only need to define all the imports/aliases in one file.