Fixing .iex.exs

A while back I made a PR to fix how .iex.exs worked so that it loaded the global/project versions correctly.

It was denied because it was not backwards compatible.

Still today, if you have an .iex.exs file that contains an import statement like the following, it crashes.

import Ecto.Query

Causes

$ iex                                                                                                                ‹ruby-2.3.1›
Erlang/OTP 18 [erts-7.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Interactive Elixir (1.2.5) - press Ctrl+C to exit (type h() ENTER for help)
Error while evaluating: /Users/mattwidmann/code/elixir/my_project/.iex.exs
** (CompileError) .iex.exs:3: module Ecto.Query is not loaded and could not be found

Does anyone else have this trouble? Would there be support for fixing these things in 1.3 or later?

1 Like

I think you’d need to run iex -S mix to use non-stdlib code in your .iex.exs. See: https://github.com/phoenixframework/phoenix/issues/1665

I too would like a solution to this. It is often very convenient to have imports on my .iex.exs but doing so prevents a bare $ iex session which is rather inconvenient. I’ve tried a variety of ways to no avail I’m afraid.

@wojtekmach yes I’m aware. The problem isn’t with running iex -S mix, but rather the bare iex session as @benwilson512 mentioned. Sometimes I don’t want to start up the app and start the supervision tree. I just want to run something in the standard library.

@benwilson512 I have found a way to work, but I’d rather not have to have that hack in there. I can’t find the hack now but I think I had to either check function_exported?/2 or something like that. Not sure if that will work or not, I do remember it being one of the things I tried though as well as catching the exception by the failed import.

You can always use “iex -S mix run --no-start” to have all your project code and dependencies loaded, but no applications started.

1 Like

This still requires that the code compile. Yes I realize that there is a no compile flag. With every required flag the convenience decreases. At this point I just have aliases in my .iex.exs. A real solution that allows a regular iex call would be best.

I think the real problem is as @benwilson512 stated, allowing a bare iex session even if the .iex.exs can’t be compiled.

Additionally it’d be nice to do something like my rejected PR did, which allows proper handling of the global .iex.exs when present.

Do you think iex should just print a warning or compiler error when you start it up and continue loading?

May not be the perfect solution but you could override the .iex.ex file like below

alias bare-iex='iex --dot-iex <(echo "")'

Using this alias bare-iex should work without loading the .iex.exs file

Thats a great workaround, but I’d like to see an official solution to this problem.

When I get some time, I may submit a PR to allow compiling to fail when loading iex and just have it print out the exception. It’d be noisy but it would at least work that way.

In Elixir v1.3, you can do import_if_available and import_file_if_available. Both will be a no-op if the module or the file do not exist. Both should fix all problems mentioned in this thread.

4 Likes

Yay!!!

1 Like

Awesome! :+1:t2: