Automatically detecting ports

[mauricioszabo]

So, this PR (#235) by @rafd added a way to auto-fill the port for Socket REPL, nREPL, and Shadow-CLJS by default.

But I saw some issues while using it:

1. Chlorine (and Clover also) is a package that wants you to connect to Socket REPL
2. There's no specific config, or anything, that creates a .socket-repl.port on the root file. In fact, there's nothing on the specification of Socket REPLs at all to create this file
3. But there is a specification for nREPL to create this port

This means that, in practice, Chlorine will default to nREPL - that's exactly the protocol he's not great at handling. I'm really thinking on alternatives, maybe even hide this "suggest port" over a config file, because keeping it the way it is, it's not painting a good image on the plug-ins' capabilities IMHO...

[seancorfield]

Perhaps add a setting to select the dot file to look for? I suspect a given user is going to use a specific type of REPL for nearly all of their projects anyway. I'm never going to want Chlorine/Clover to use .nrepl-port; I'm only ever going to want it to use .socket-repl-port.

So perhaps a text field that folks can put a comma-separated list of dot-file names in order to search for?

[rafd]

Some other options to consider:

• recommend that people manually create a .socket-repl-port file (since you're already asking them to add the relevant config to deps.edn)
• show a checkbox list of options when multiple sources detected, always including Socket REPL (empty by default)
• try to parse deps.edn for the port

[rafd]

Out of curiosity, what additional advantage does Socket REPL currently have over nREPL?

[seancorfield]

@rafd I think you're starting to over-complicate things at this point: Chlorine/Clover are great because they are simple and generally just "do the right thing" without a lot of options and interactions.

Re: Socket REPL -- the great advantage for me is that socket REPL is built into Clojure itself and requires no code and no dependencies: I can use just a JVM option when starting any process to get Clojure to start a socket REPL on a given port (or even have it auto-select an available port). I can then use Chlorine/Clover to connect to any Clojure process that is running a socket REPL -- a local one for dev, a remote one (such as on production) for debugging -- and it's the exact same editor experience. No extra libraries, no dependencies.

[mauricioszabo]

@rafd to be honest, nREPL is better as a tooling assist. But it only works well for Babashka and Clojure, and even Clojure needs an additional dependency (something that may be not present on production environments for example, if you want to remotely debug code).

On Clojerl, Clojure.CLR, Plank, Lumo, Joker, and experimental Clojure implementations they always add a Socket REPL, so Chlorine can be used to connect to "esoteric Clojure implementations". Apart from that, nREPL is better in any other way for tooling.

Chlorine (and Clover) really shine because they use some interesting techniques over Socket REPL. Yes, it's harder to program on it, and I would probably be better by using nREPL, but there are already lots of packages for nREPL and I don't want to reinvent the wheel or take their places.

So, the focus of this package is Socket REPL. It works with nREPL also, but it's more like a "nice-to-have" and it still have its quirks, so that's the reason I'm afraid to make it an "easier option" for people to use :)

[mauricioszabo]

Also, nREPL over CojureScript is kind of a pain, really...