This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # beginners (42)
- # biff (11)
- # calva (15)
- # cider (3)
- # clj-http-lite (3)
- # clojure (52)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (39)
- # clojure-uk (4)
- # clojurescript (52)
- # code-reviews (13)
- # conjure (1)
- # cursive (4)
- # data-science (1)
- # datomic (5)
- # emacs (6)
- # events (3)
- # graalvm (5)
- # hyperfiddle (7)
- # kaocha (14)
- # lsp (11)
- # malli (3)
- # nbb (13)
- # off-topic (87)
- # pathom (15)
- # polylith (23)
- # portal (5)
- # reitit (4)
- # shadow-cljs (110)
- # squint (114)
- # testing (1)
- # vim (13)
Should Calva be using
cider/orchard instead of
I personally have no idea at the moment what features are being used, how they are being used, how much work it would take to switch, or any number of other factors that would go into answering such a question. Just proposing it for consideration in case nobody has thought about it yet.
I thought Orchard was more of a library from which cider-nrepl is built. What's the difference?
Yeah, that's more or less correct. From what I gather, most of
cider-nrepl's core functionality was extracted out into
orchard as a major step toward making it environment agnostic.
Even though development of
cider-nrepl itself has also moved strongly toward agnosticism, it's primary target is
CIDER, which is specific to Emacs. And even though it is already more-or-less editor agnostic, it definitely still depends on
Basically just thinking that we already implicitly depend on
cider-nrepl. What if
orchard has everything we need on its own? If so, it might make sense to remove that level of indirection.
orchard is repl-agnostic, we would also be opening a path forward to consider maybe removing
nrepl as a dependency some time in the future.
cider-nrepl was merely chosen because of its obvious connection with
nrepl. Or maybe
orchard simply wasn't yet feature complete when Calva was started. ... Or maybe what we require is exactly what
cider-nrepl adds on top of
orchard, making it a simple choice not to change anything. I really don't know enough about the codebase to make any strong suggestions here.
I just wanted to bring it up, so you and other maintainers can ponder it as an option. Or perhaps just asking will stir up inspiration for someone to hack together a proof of concept.
I really didn't know what I was doing when I made Calva, so cider-nrepl wasn't a super informed choice. Calvados is made from cider, though, so I mostly just did what CIDER did. Would be interesting to hear @bozhidar share some insights into the matter.
The “problem” with orchard is that you’re getting the functionality but not the ease of tool use. So we’d have to switch our tooling to using actual calls instead of nrepl middleware. Plus stuff like the debugger is part of cider-nrepl. Since Calva doesn’t use that many middleware points it wouldn’t be a huge switch but quite a bit of work non the less.
cider-nrepl goes best with nREPL usages - it's as simple as that. Orchard was extracted from
cider-nrepl mostly to be used with a socket REPL (or some other REPL) or to be used by nREPL clients who prefer to just use eval ops for tooling purposes instead of special ops.
I'm not sure how exactly Calva supports multiple REPL types, but I think that for nREPL using
cider-nrepl is better than evaling stuff from Orchard directly.
(e.g. using the debugger would be impossible without
cider-nrepl as it was never extracted to Orchard)
Thanks, @bozhidar! Then things are much like I thought they were. Currently Calva is nREPL only. If we would make it support socket repl it would make sense to use Orchard more directly. (And the debugger would remain nREPL only.)
Obviously, I'm kind of biased as I strongly favor both structured requests and responses and with a socket REPL this disappears - this simply works better with editors and similar tooling. With prepl at least you get structured responses for eval.
I'm biased the same way as you, @bozhidar 😃 nREPL is one of the most awesome pieces of software I have ever encountered.
Well, if it's nREPL only there it makes little sense to switch to Orchard. A few years ago I was planning to add socket REPL support to CIDER as well, which was much of the motivation for the work on Orchard to start, but after playing with the socket REPL for a while I decided it wasn't a good fit for editors and then I became the maintainer of nREPL and just fixed whatever problems I had identified there. 🙂
I wrote a bit more on the different REPLs here https://nrepl.org/nrepl/1.0/alternatives.html#socket-repl