I tried to use the current approach (code_reload in the config file) setup to use a node from my local rebar3 dist_node setting.
With a cookie setup in the rebar3 dist_node config, I realized erlang_ls was missing cookie settings for code_reload (it only has one for its runtime node). I had not seen this GitHub issue, so I started adding a cookie setting to erlang_ls.config and that worked just fine with the code reloading.
I then saw this issue before starting making a PR to add cookie configuration for code_reload.
Reading the code there is configuration and a lot of code for the runtime node, but it doesn't appear like anything is calling the connect function to start or attach to a runtime node with the default name. The default name is used by the rpc_call function (which code reloading would use, I presume, since it is used today but for a different node).
I can see erlang_ls starting nodes with timestamped names like erlang_ls_erlang_example_10210420@localhost. Is this intended to be reworked, or will they run in addition to the default names runtime node?
If this is not ready to get started yet, I can open a pull request with just my cookie fixes for the current code_reload feature.
I would not mind taking a look at this.
I tried to use the current approach (code_reload in the config file) setup to use a node from my local rebar3 dist_node setting.
With a cookie setup in the rebar3 dist_node config, I realized erlang_ls was missing cookie settings for code_reload (it only has one for its runtime node). I had not seen this GitHub issue, so I started adding a cookie setting to erlang_ls.config and that worked just fine with the code reloading.
I then saw this issue before starting making a PR to add cookie configuration for code_reload.
But, it is unclear to me just how complete the runtime node setup is. According to https://github.com/erlang-ls/erlang_ls/blob/main/specs/runtime_node.md it seems to be planned.
Reading the code there is configuration and a lot of code for the runtime node, but it doesn't appear like anything is calling the
connect
function to start or attach to a runtime node with the default name. The default name is used by the rpc_call function (which code reloading would use, I presume, since it is used today but for a different node).I can see erlang_ls starting nodes with timestamped names like
erlang_ls_erlang_example_10210420@localhost
. Is this intended to be reworked, or will they run in addition to the default names runtime node?If this is not ready to get started yet, I can open a pull request with just my cookie fixes for the current code_reload feature.