Elixir: Should IEx.Server be considered a private API?

[ConnorRigby]

While building a feature for NervesHub, I've wrapped IEx.Server with a new group_leader to allow for tunneling IO over a Phoenix Channel. This all _feels_ alright, but I know with a recent Elixir version upgrade, some things that were considered private changed breaking some projects. I'd like to prevent this (even though there is only _one_ call into IEx.Server)

For what it's worth here is the implementation.

[josevalim]

@ConnorRigby not sure if it will be directly via IEx.Server but we should have a way to start an IEx session. :+1:

[josevalim]

Hi @ConnorRigby !

I have published IEx.Server.start/1 as public API for now. I think it is worth mentioning though that some features won't work (namely the ones related to pry/breakpoints). The issue is that today we are only able to locale an IEx.Server attached to the user_drv. You can see the (horrible) implementation here:

https://github.com/elixir-lang/elixir/blob/b20bf5a0d49cf3c85d6ebb1a193b25147e02da30/lib/iex/lib/iex/server.ex#L32-L57

I think it would be nice if breakpoints also worked on other places. The issue is how do you control on which session should we start the debugging session.

1. For example, in case of websockets, what if you have many terminals opened?
2. In case you have both websockets and iex, which one to use?

I guess one option to explore is to allow any of them to take over and then the first one that answers yes wins. But this is annoying to implement in practice because we would need to introduce a middle man process for handling this negotiation. The other issue is that, should we rely send this to all websocket connections? Wouldn't it be better to send it to whatever we consider as active?

One workaround is to allow a single process name IEx.Server to be the recipient of those messages, if it exists. But then you need to manage the multiple tabs and make sure only one of them is the active one.

Thoughts?

[ConnorRigby]

Thanks for making that API public it will be helpful.

I think it would be nice if breakpoints also worked on other places. The issue is how do you control on which session should we start the debugging session.

This is something i hadn't even really considered yet. What about having a public take_over api? That way whoever had the Server would have to manually declare themselves as the debugging process. I feel like i remember seeing a takeover() function in one of these modules.

[josevalim]

@ConnorRigby the take over is not really the problem. The issue is that when you call IEx.pry or IEx.break you call it from an external process that knows nothing about IEx or which IEx processes are running. So we need to "find it out". Does it make sense?

[ConnorRigby]

Oh i understand now. I admittedly don't use pry and break very often, but it would be pretty nice for this to work.

If i remember correctly there is a Request to Pry (Y/n) message correct? I think one solution might be to prompt _every_ IEx.Server, and whichever one answers gets to pry that session. (i'm not sure if it works the same for break)

this is assuming the prompt is a simple gets call.

[josevalim]

@ConnorRigby right, we can do this, but then we will need to introduce a broker process to broke between the take overs and the shells. I guess that's the correct solution anyway, so I guess we should just go ahead and do it.

[josevalim]

After all, it is exposed as IEx.Server.run/1. We have also added the ability to choose which one of multiple sessions will enable the debugger.