.iex.exs for releases?

Is there a way to make an equivalent for .iex.exs for releases, where a handful of modules are aliased or imported that are useful for the operator in the shell in deployment, or should we just ship .iex.exs to the home directory of the deployment?

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.

2 Likes

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.

2 Likes

@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 :slightly_smiling_face:

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.

2 Likes