by no effect I mean that if I start a repl from a buffer (where that variable is set to that string)

I doin't see any banner when the repl starts up

just

;; Connected to nREPL server - 
;; CIDER 1.13.0-snapshot (package: 20231204.843), nREPL 1.0.0
;; Clojure 1.11.1, Java 17.0.9
;;     Docs: (doc function-name)
;;           (find-doc part-of-name)
;;   Source: (source function-name)
;;  Javadoc: (javadoc java-object-or-class)
;;     Exit: <C-c C-q>
;;  Results: Stored in vars *1, *2, *3, an exception in *e;
user> 

that var only works as a boolean flag, from what I see

ah right yes

so the banner is fixed from cider-repl--help-banner ()

mm ok I was sure it was possible to override it for some reason

I guess I can just redefine that function in theory

a bit hacky though

Yes. It would SGTM to extract the string to a defcustom, please create an issue so that others can share their opinion

ok cool

https://github.com/clojure-emacs/cider-nrepl/issues/838

I've worked on cider-pprint-eval-last-sexp error handling quite recently, feel free to create an issue explaining the use case

I guess there is no way to make the remote one sync with your local env anyway

or are people using socket/prepls maybe for prod/dev repls?

I wouldn't include cider-nrepl into a production app - it can bloat the dependency tree and create a variety of unforeseen behaviors. However including nrepl/repl, and spawning a nrepl server from there, is more minimalistic and quite usual. You wouldn't add cider-nrepl, refactor-nrepl or other pieces of middleware in this nrepl server. When connecting to it from cider, you'd get a warning about missing middleware, which is perfectly fine to ignore. (You'll get a variety of basic features working, but others won't. Normally we fail-fast on absence of middleware support, so it's all pretty clear to end users)

...There are alternative patterns as well, for instance leaving the prod app entirely untouched and create a 'sidecar' JVM process with cider-nrepl (all of it). This way, you get nice extra features (cider-inspect can be definitely handy for production) without the side-effects, and if something goes terribly wrong, process isolation would save you.

What @vemv describes is what we do (include nrepl as a dep, etc). It works well for us.

ah ok interesting

any examples o f the sidecar JVM approach as well?

(ns system
  (:require
   [cider.nrepl :refer [cider-nrepl-handler]]
   [clojure.core.server :as server]
   [integrant.core :as ig]
   [io.pedestal.http :as http]
   [nrepl.server :as nrepl]))


(defmethod ig/init-key ::nrepl-server [_ {:keys [port]}]
  (assert (some? port), "Missing port")
  (println "Starting nrepl server on port " port)
  (nrepl/start-server :port port
                      :bind "0.0.0.0"
                      :handler cider-nrepl-handler))

ah and actually I was starting the nrepl server with cider-nrepl-handler

so I guess I have to change that if I should not include cider-nrepl as dependency

yeah ok that was easy ,just had to remove that and it fallsback to the default handler

> any examples o f the sidecar JVM approach as well? (edited) Not that I know of. Maybe I'd simply make sure a git clone of the project is available, so that I can spawn a repl on demand with a simple command like lein repl But sky is the limit 🙂 one could also devise a detailed Dockerfile

mm yeah I probably would not do that

we just keep the docker images minimal with just the jdk installed

better to just include nrepl in the dependencies then