Extend the "describe" op with some extra runtime information

[bbatsov]

Is your feature request related to a problem? Please describe.

Today it's hard to tell what's the runtime of the server you're connecting to (e.g. Clojure, ClojureScript, ClojureCLR, babashka, or some non-Clojure language like Racket, fennel, etc.).

One practical problem is that client often implement some functionality in terms of evaluating runtime-specific code, which often means that one client can't be used with different nREPL servers simply because it makes some assumptions that are not universally true.

If clients could easily infer that runtime of the server they can support easily different runtimes.

Describe the solution you'd like

I think we should agree that every nREPL server should return some extra metadata in the describe op:

• runtime/language (e.g. Clojure)
• protocol version (tracking the version number of the reference nREPL implementation) - not sure how useful this can be, but it won't hurt. I guess potentially this can be nrepl-version.
• name of the server implementation (e.g. Ogion)
• version of the server implementation (this should be different from nrepl-version I guess)

E.g. you can have something like:

{:runtime "racket"
  :protocol-version "0.7"
  :implementation-name "ogion"
  :implementation-version "0.1.0"}

Describe alternatives you've considered

I didn't manage to think of a good alternative.

@nrepl/nrepl @technomancy @borkdude setzer22 Let me know how this sounds to you.

[borkdude]

In the case of babashka, should the runtime be "clojure" or "babashka"? Babashka mimics JVM Clojure as close as possible, but some things aren't supported like defprotocol. I'm not sure what to put as the nREPL protocol version. I just use bencode and reverse engineered what was necessary to make CIDER's cider-connect and lein repl :connect work.

{:runtime "babashka" ;; or "clojure" ?
  :protocol-version "??"
  :implementation-name "??"
  :implementation-version "??"}

[technomancy]

I like this idea, except I really don't think "protocol-version" should be included at this point. Conflating the protocol with the reference implementation is a very bad idea. If we come up with an independent document describing the protocol on its own and version that separately, then it could make sense to include this in the description, but I'm not aware of any such thing at this time.

[bbatsov]

I finally started working on this today, so I'll have some update soon. Now I'm leaning towards adding a runtime and name/server (short for "implementation/server name") key at the top-level of the describe map. Servers will still put their relevant versions in the versions map, but clients would know what to look for based on the runtime/server keys (e.g. if runtime is clojure/babashka they'll look for clojure/babashka and java version info). If in the case of fennel they'll look for fennel and lua version info and so on.

@borkdude In your case runtime should be "babaska", "name" whatever you want (e.g. nrepl-babashka) and same with the version:

{:runtime "babashka"
  :name "nrepl-babashka"
  :versions { :babashka "..."
                     :java "..."
                     :nrepl-babashka "..."}}

Let me know how this sounds to you and whether you have some preferences about the names of the extra keys.

[bbatsov]

Btw, I guess for babashka the runtime can easily be clojure as well, given how highly compatible they are. That's not a big deal in the end of the day I think.

[borkdude]

Having a separate version / java from version / babashka doesn't make sense, since you cannot have different Java/GraalVM versions with the same babashka version, i.e it's a derived property. From 0.1.0 on babashka is compiled with GraalVM java11 (right now GraalVM version 20.1.0).

I think the field "name" could have a more descriptive name. What is this going to be used for? In the case of babashka there is only one possibility: [babashka.nrepl]

To summarize, I think for babashka this makes sense:

{:runtime "babashka"
 :versions {:babashka "0.1.0"}}

and that's about it?

[bbatsov]

Having a separate version / java from version / babashka doesn't make sense, since you cannot have different Java/GraalVM versions with the same babashka version, i.e it's a derived property. From 0.1.0 on babashka is compiled with GraalVM java11 (right now GraalVM version 20.1.0).

Got it. Well, one less version then.

I think the field "name" could have a more descriptive name. What is this going to be used for? In the case of babashka there is only one possibility: [babashka.nrepl]

For most runtimes there's just one server currently, so potentially we can skip this. There's no guarantee there won't be more servers down the road, but there's also no real need for premature optimization at this point.

and that's about it?

Fine by me.

[bbatsov]

Btw, doesn't your nREPL server have different versioning from babashka - I guess it still might be nice to include its version so that clients could display it.

[borkdude]

@bbatsov True that. We could add :babashka.nrepl "0.0.4" to versions?
https://github.com/babashka/babashka.nrepl/blob/c3bfaff12c84d269e0d1c6110c290d5c5a08e002/project.clj#L1

[bbatsov]

We have a deal! 🤝

[borkdude]

@bbatsov There are other projects that use babashka.nrepl as their nREPL server. Their runtime, like babashka, is based on the sci interpreter. I made a proposal here for these projects:

babashka/babashka.nrepl#17

Is this information going to be used by CIDER? Would it be useful to have one common key so CIDER doesn't have to add cases for each new sci-based project? It's not always clear what a sci-based project will or won't support though, since sci is just an interpreter. What it can provide depends on how people use the interpreter. So it's likely that an nREPL client will still have to try things with resolve etc. to determine what the nREPL server can do.

[bbatsov]

Is this information going to be used by CIDER?

Yeah, it will be. The plan is to have CIDER support better non-Clojure nREPL servers See clojure-emacs/cider#2848 for more details. As an immediate step for babashka I wanted to make some changes that would eliminate the warnings they are getting from CIDER today. Unlike a language like Fennel it doesn't really require much internal changes, as most of the Clojure code that CIDER runs will work just fine.

So it's likely that an nREPL client will still have to try things with resolve etc. to determine what the nREPL server can do.

Well, if the runtime is not Clojure-like we can't even try resolve. :-) That's why the runtime info is the most important one.

[borkdude]

@bbatsov If that's the goal, maybe for runtime it's better to use some namespaced thing, so the project can describe it's some flavor of Clojure?

:runtime "clojure/babashka"

:runtime "clojure/bootleg"

:runtime "clojure/clojurescript"

So then CIDER knows by the namespace of the key that it can use require?

Or a separate :language key that says "clojure".