Clojurians Log v2

never used sideloading, I don’t see what I would use it for

The two scenarios I can think of that would be useful: • sideload nREPL itself (+ other middleware?) into a bare socket REPL -- the latter can be started automatically via JVM options, but you only need nREPL etc if you actually want to connect a dev-experience IDE to it • sideload CIDER etc into a bare nREPL -- to avoid needing anything more than nREPL bundled into a remote process I had hoped for the former, so we wouldn't need to bundle nREPL into any production apps and could then use JVM opts to start a socket REPL and upgrade it via tooling. In the end, we compromised by bundling nREPL into a couple of our internal-facing apps and using a bare nREPL for debugging without middleware. And then I decided to add Portal to one of those so I can use its visualization remotely for debugging (which drags a lot of stuff into the app which... makes me a bit sad).

At this point tho', since it never actually made it into any tooling (right?), I think it would be OK to kill it so you don't have the drag of any future maintenance or code bloat aspects.

Yeah, it didn’t gain any traction (even CIDER doesn’t really use it) and it seems there’s little point in investing in it further, unless we have some really strong use-case. There are other ways to load dynamically middleware that are potentially simpler and more robust (e.g. dynamic middleware loading using add-lib internally)

Aye, except you can't (easily) use add-lib from a running production process with nREPL connected since that's tied to something clojure.repl sets up right? (and it requires clojure to be installed and accessible on the server since it shells out to it, in order to add new dependencies -- although we do have clojure on all our servers to support maintenance/deployment tasks)

//cc @alexyakushev

Yes, add-lib requires clojure to be installed and available on PATH. It is because clojure is used as a dependency resolver/artifact downloader. Doing it otherwise would require bundling something like Pomegranate with nREPL which is a dependency hell among other things. That's what Boot used to do, btw. So, nREPL will unlikely ever include a complete alternative to add-lib. It's current sideloading capabilities are limited to loading literal JARs that are fed to it via the network by the client. So, the client would be the one to do dependency resolution and fetching. And that's one of the reasons why sideloading in its current form is not very useful.

> Yes, add-lib requires clojure to be installed Not necessarily 👿 https://github.com/borkdude/deps.add-lib

That's a fair point, but keep in mind we meant to load with it mostly self-contained libraries without deps (think compliment, orchard, middleware with inlined deps, etc). E.g. if it could load compliment it would and instruct nREPL to use it instead of the bundled compliment-lite and things along those lines. So, in theory it could be useful despite being quite primitive.

I think hotloading deps with pomegranate works with nREPL (or at least it worked in some point), but I'd never bundle it with nREPL. Whoever wants to use it can easily add it to their own projects.

That's a fair point, but keep in mind we meant to load with it mostly self-contained libraries without deps (think compliment, orchard, middleware with inlined deps, etc).Right. But the main problem then is for the client to get hold of that Compliment JAR. You went through that yourself with CIDER (I've seen that in some tickets). Should it scan the local ~/.m2/ dir? Should it bundle the JARs together with the client installation (you wanted to ship CIDER with cider-nrepl bundled AFAIR)? All of that is doable, of course. The question is whether anyone is willing to take that route. BTW, cider-nrepl now has a couple transitive dependencies.

Yeah, yeah - all of that is fair. It definitely turned out to be more complicated that I had originally thought it'd be. Personally, I'm leaning towards just pulling the plug on the sideloader and focusing our attention elsewhere.

Given that the main part of this feature is loading dependencies at runtime (the other being middleware manipulation), and Clojure 1.12 is about to introduce a "sanctioned" way to do that (being constrained by tools.deps usage, but still), here is one of the viable strategies that I see: 1. Wait for Clojure 1.12 to be released, see if add-lib is usable and if people use it. 2. See if Leiningen does anything about it – if it somehow makes add-lib work in Leiningen-based projects. 3. Once the dust settles, we can revisit this and see if nREPL can leverage add-lib and if it has to at all – maybe add-lib will completely cover the sideloading usecase. Until that happens, we can either leave the sideloading in the current state or get rid of it and build it anew later if necessary. I have no strong preference for either case.

I was using the vim-iced sideloading support. It has worked in a cases where adding the middleware to the projects isn't as easy / I don't control nrepl server creation. Like a project with ~30 nrepl servers running in "micro"services in docker containers. But with lsp it might be I don't even need the features cider-nrepl provides, I need to test how basic stuff like just sending forms to the repl works without it.