Interaction test fails conflicting with .iex.exs file

[Eiji7]

Elixir and Erlang/OTP versions

This issue is not related to Erlang and I've confirmed it exists in both latest release and the main branch.

Operating system

N/A - it should happen on every ANSI-compatible dev machine with custom .iex.exs

Current behavior

In .iex.exs file located in my home directory I have set eval_error to :light_red. The test is setting it to :red and therefore tries to override it in:

elixir/lib/iex/test/test_helper.exs

Lines 102 to 110 in 51e160e

	def capture_iex(input, options \\ [], server_options \\ [], capture_prompt \\ false) do
	IEx.configure(options)
	ExUnit.CaptureIO.capture_io([input: input, capture_prompt: capture_prompt], fn ->
	server_options = Keyword.put_new(server_options, :dot_iex, "")
	IEx.Server.run(server_options)
	end)
	|> strip_iex()
	end

However for some reason .iex.exs is still preferred which ends up in failing test. Therefore if (for test purposes) we set all colors to some rarely used one we may be able to break every test which tests ANSI escape codes response.

In my case the mentioned test is located here:

elixir/lib/iex/test/iex/interaction_test.exs

Lines 154 to 161 in 51e160e

	test "color" do
	opts = [colors: [enabled: true, eval_result: [:red]]]
	assert capture_iex("1 + 2", opts) == "\e[31m\e[33m3\e[0m\e[31m\e[0m"
	assert capture_iex("IO.ANSI.blue()", opts) == "\e[31m\e[32m\"\\e[34m\"\e[0m\e[31m\e[0m"
	assert capture_iex("{:ok}", opts) ==
	"\e[31m\e[39m{\e[0m\e[31m\e[36m:ok\e[0m\e[31m\e[39m}\e[0m\e[31m\e[0m"
	end

Expected behavior

When I've noticed that the tests are calling IEx.configure/1 (as same as my .iex.exs file) I was really surprised. I guess that .iex.exs evalution happens somewhere in between and it's worth investigating why tests are not overriding it as similar conflict may exist also in different places.

I'm not even sure how important this issue is as I guess it's good that .iex.exs in typical case is preferred, but also moving away this file just to test Elixir is not handy …