Elixir installer on Windows 10 installs Elixir and IEx as broken
bmitchell-cfs opened this issue · 6 comments
Environment
-
Elixir & Erlang/OTP versions (elixir --version):
-
Elixir does not run, but Elixir 1.10.3 was selected to be installed.
-
The Erlang version, as reported by the installer is 9.2.
-
-
Operating system: Windows 10, version 1909, OS build 18363.900
Current behavior
The Windows installer found here does not properly install Elixir. The installer reports no errors, but after installation, both iex.bat and elixir.bat fail by crashing. The application werl.exe fails similarly but then automatically closes without the user being able to inspect the crash.
When running iex.bat in Windows Terminal with PowerShell, I get:
> iex.bat
2020-06-19 02:16:39 Loading of ~ts failed: ~p
"c:/Program Files (x86)/Elixir/lib/iex/ebin/Elixir.IEx.CLI.beam"
badfile
2020-06-19 02:16:39 ~s~n
"beam/beam_load.c(1862): Error loading module 'Elixir.IEx.CLI':\n This BEAM file was compiled for a later version of the run-time system than 20.\n To fix this, please recompile this module with an 20 compiler.\n (Use of opcode 162; this emulator supports only up to 159.)\n"
2020-06-19 02:16:39 crash_report
initial_call: {supervisor_bridge,user_sup,['Argument__1']}
pid: <0.49.0>
registered_name: []
error_info: {error,undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,"user_sup.erl"},{line,100}]},{user_sup,init,1,[{file,"user_sup.erl"},{line,49}]},{supervisor_bridge,init,1,[{file,"supervisor_bridge.erl"},{line,80}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
ancestors: [kernel_sup,<0.36.0>]
message_queue_len: 0
messages: []
links: [<0.37.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 987
stack_size: 27
reductions: 223
2020-06-19 02:16:39 supervisor_report
supervisor: {local,kernel_sup}
errorContext: start_error
reason: {undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,"user_sup.erl"},{line,100}]},{user_sup,init,1,[{file,"user_sup.erl"},{line,49}]},{supervisor_bridge,init,1,[{file,"supervisor_bridge.erl"},{line,80}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
offender: [{pid,undefined},{id,user},{mfargs,{user_sup,start,[]}},{restart_type,temporary},{shutdown,2000},{child_type,supervisor}]
2020-06-19 02:16:39 crash_report
initial_call: {application_master,init,['Argument__1','Argument__2','Argument__3','Argument__4']}
pid: <0.35.0>
registered_name: []
error_info: {exit,{{shutdown,{failed_to_start_child,user,{undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,"user_sup.erl"},{line,100}]},{user_sup,init,1,[{file,"user_sup.erl"},{line,49}]},{supervisor_bridge,init,1,[{file,"supervisor_bridge.erl"},{line,80}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}}},{kernel,start,[normal,[]]}},[{application_master,init,4,[{file,"application_master.erl"},{line,134}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
ancestors: [<0.34.0>]
message_queue_len: 1
messages: [{'EXIT',<0.36.0>,normal}]
links: [<0.34.0>,<0.33.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 987
stack_size: 27
reductions: 243
2020-06-19 02:16:39 std_info
application: kernel
exited: {{shutdown,{failed_to_start_child,user,{undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,"user_sup.erl"},{line,100}]},{user_sup,init,1,[{file,"user_sup.erl"},{line,49}]},{supervisor_bridge,init,1,[{file,"supervisor_bridge.erl"},{line,80}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}}},{kernel,start,[normal,[]]}}
type: permanent
{"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{{shutdown,{failed_to_start_child,user,{undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,\"user_sup.erl\"},{line,100}]},{user_sup,init,1,[{file,\"user_sup.erl\"},{line,49}]},{supervisor_bridge,init,1,[{file,\"supervisor_bridge.erl\"},{line,80}]},{gen_server,init_it,2,[{file,\"gen_server.erl\"},{line,365}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,247}]}]}}},{kernel,start,[normal,[]]}}}"}
Kernel pid terminated (application_controller) ({application_start_failure,kernel,{{shutdown,{failed_to_start_child,user,{undef,[{'Elixir.IEx.CLI',start,[],[]},{user_sup,start_user,3,[{file,"user_sup.
Crash dump is being written to: erl_crash.dump...done
When running elixir.bat --version in Windows Terminal with PowerShell, I get:
> elixir.bat --version
{"init terminating in do_boot",{undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{file,"init.erl"},{line,1085}]},{init,do_boot,3,[{file,"init.erl"},{line,793}]}]}}
init terminating in do_boot ({undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{_},{_}]},{init,do_boot,3,[{_},{_}]}]})
Crash dump is being written to: erl_crash.dump...done
Expected behavior
The expectation is that the installer should just work. The crash message seems to imply a version mismatch with Erlang, but the installer should properly install both Erlang and Elixir with the correct versions.
Hi @bmitchell-cfs! It seems there was already an Erlang installed in the system but it was an old installer. Can you please run the installer again and then make sure that you install the most recent Erlang version too? You can also pick the most recent Erlang from here too: https://www.erlang.org/downloads
Thanks for the information. I didn't install Erlang myself. Looking into this further, it seems Erlang 9.2 was likely installed by some National Instruments software, which seem to use RabbitMQ. Reading the language more closely, I see that the Elixir installer was choosing to use the already installed Erlang 9.2 rather than doing the install itself, which was what I originally assumed.
Should this be transitioned to a bug or feature instead of being closed? I think closing this without understanding the complete issue is premature. Because I think that the installer should automatically install a compatible version of Erlang. If it can't, then it should warn that the installed version is not compatible and not allow configuration with the incompatible version. The expectation on Windows is that installers should not leave the installed software broken and should instead handle the issue automatically or warn. So I think the issue potentially transitions to "the Elixir installer should not allow configuration with an incompatible Erlang version" with a proposed fix of automatically installing a compatible version or warning of the incompatibility and not continuing.
Some additional information is that even after uninstalling Elixir, then manually installing the latest version of Erlang (Erlang/OTP 23.0), and then re-installing Elixir, the Elixir installer still automatically suggests configuring with the earlier, incompatible version, even though there is a later, compatible version installed.
And even after pointing Elixir to the correct version of Erlang, in this case 23.0, the installer does not successfully install Elixir, as I still get crashes. It appears the crashes are the same as above, so it seems that even after pointing the installer to Erlang/OTP 23.0, Elixir is still using Erlang 9.2. This is path related, because when I type erl into a terminal, I get the Erlang 9.2 version. The Elixir installer explicitly asked me if I wanted it to add Erlang/OTP 23.0 to my path. (I didn't take a screenshot of this but confirmed it did add it to my system path.) The Elixir tooling is just using whatever Erlang is returned first in the path, which is a separate issue, in my opinion. It should use the version I pointed it to during the installation process and not use whatever Erlang comes first in the system or user path, at least that is the expectation. I confirmed this is the case by moving erl-23.0 above (earlier than) erl9.2 in the system path, and with no other changes, iex.bat now runs successfully.
I would summarize the outstanding issues as:
- The Elixir installer should automatically install a compatible version of Erlang if one is not installed.
- The Elixir installer should not allow configuration with an incompatible Erlang version.
- The Elixir installer should automatically recognize the latest installed version of Erlang.
- The Elixir Installer and/or Elixir tools, should properly honor the requested Erlang version configuration and should not use whatever Erlang is returned first in the path.
Hi!
I understand the desire to force Elixir to point to a specific Erlang version, but given that both Elixir and Erlang are development tools, I would be weary of moving to this direction. For example, Elixir developers use rebar and make to compile Erlang and native packages and they are separate tools that are going to use the Erlang installed in your PATH. You may come across other tools, such as escripts, that you use on your day-to-day as an Elixir developer that will rely on the Erlang version in PATH and they won't work as expected if each of them use a different Erlang version. This means that forcing Elixir to use a hardcoded Erlang version not from PATH is going to lead to issues down the road.
When it comes to PATH, Windows builds the PATH from multiple configurations. It seems erl9.2 was put in a place with higher preference than Elixir's - this is typically the SYSTEM one. But installing on the SYSTEM one is usually seen as bad practice, so if we do this change, then others may not be pleased.
Similarly, you could be using RabbitMQ and us simply overriding Erlang would break your RabbitMQ installation. I don't see an obvious answer for this: you have two projects that want to use different versions of another project and one of them has to "win". I could argue that RabbitMQ should be the one hardcoding the Erlang installation, because it is a "finished product" rather than a development tool, but they may have their reasons too.
All in all, I understand the annoyance when things do not work out of the box, but I am not sure if there is an obvious answer here. This is not even a Windows specific issue, conflicting installs also happens on Unix systems, perhaps even more frequently.
I'll provide context on the installer's implementation then use this to address your summary of the issues.
In order to determine which Erlang versions are installed, if any, the installer scans the registry for subkeys at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ericsson\Erlang on 64-bit installs and SOFTWARE\Ericsson\Erlang on 32-bit installs. If possible, please report what your system has at these subkeys.
- The Elixir installer should automatically install a compatible version of Erlang if one is not installed.
The installer pulls the latest Erlang version if no Erlang install exists. It is assumed that the latest version is compatible with at least a few of the most recent Elixir releases. I presume the dominant installer use case is to install the latest version of both E's with neither E already present on the system, so it is unlikely we would add the version compatibility information to the installer.
- The Elixir installer should not allow configuration with an incompatible Erlang version.
See answer to 1.
- The Elixir installer should automatically recognize the latest installed version of Erlang.
Agreed. The reason this isn't occurring is possibly due to a defect in the implementation I described above. Based on your screenshots there may an Erlang upstream change that's causing the version parsing to malfunction.
- The Elixir Installer and/or Elixir tools, should properly honor the requested Erlang version configuration and should not use whatever Erlang is returned first in the path.
As @josevalim mentioned, Elixir follows the precedence set by your PATH, and we wouldn't want to introduce other incompatibilities by deviating from this behavior.
Maybe the resolution is to add clarifying text in the installer wizard to at least help the user understand what it's doing with this version information.
Hi @josevalim and @chyndman. Apologies for not getting back to this sooner.
I have mainly been setting Elixir up in WSL rather than using it directly in Windows since there is a fair amount of friction on Windows, but today I needed to use a USB device with Elixir, where USB passthrough is not supported in WSL. So I ended up rediscovering this issue since I'm setting up a new Windows 10 computer.
The issue is with the detection. In my case, Erlang 10.6 was already installed by another tool (in fact, it is the same tool as mentioned above: National Instruments software suite). However, National Instruments does not add Erlang to the path. What's happening is that the Elixir installer is detecting the Erlang 10.6 (likely through the registry as mentioned above), and then if selected, the Elixir installer is what adds it to the path. This is mainly a problem if the version is not compatible with Elixir.
So I manually installed the latest version of Erlang after removing the old version from my path and then re-ran the Elixir installer. This time, the Elixir installer did correctly automatically recognize the latest installed version of Erlang, and I was able to get Elixir installed properly on Windows.
I think a fix that could happen is a detection that the latest Erlang install on the computer is not recent enough, prompting the user to download a later or the latest version of Erlang. Either that or the documentation should simply ask the user to manually install a certain version or later of Erlang.
After installing National Instruments software and running the Elixir installer:
After manually installing the latest Erlang version:
