Any way to run cider 0.7 without the middleware

[gja]

Is there any way to run cider 0.7 without the middleware installed into the app? Is there any way, say, if we have the cider jar locally, to dynamically load the /path/to/jar in the classpath, then bounce the nrepl server with the new middleware?

[gja]

Another reason to do this is that I have multiple projects, which are actually running nrepl in production (if you can SSH tunnel in). And multiple developers on my team, with different versions of cider.

Is there some minimum set of functionality which could be supported in CIDER 0.7 without any plugin loaded? Basically, whatever worked in CIDER 0.6 without the lien plugin should still be supported, right?

[bbatsov]

Is there some minimum set of functionality which could be supported in CIDER 0.7 without any plugin loaded?

The only thing supported without the middleware is evaluating code (which includes loading files and getting error feedback obviously). Pretty much nothing else will work (not even eldoc, doc lookup, etc).

Basically, whatever worked in CIDER 0.6 without the lien plugin should still be supported, right?

We've dropped all the inlined code, so no.

Another reason to do this is that I have multiple projects, which are actually running nrepl in production (if you can SSH tunnel in). And multiple developers on my team, with different versions of cider.

Once we release CIDER 0.7 (hopefully in a few days) it seems that the simplest solution would be to have everyone using it.

[gja]

OK, thanks for clearing that up.

[gtrak]

Well, theoretically you can do just what you said, you can load the middleware jar into the classpath and start a new nrepl server with the middlewares via some evals, though the first step seems the hard one.

On Wednesday, July 30, 2014, Tejas Dinkar notifications@github.com wrote:

OK, thanks for clearing that up.

— Reply to this email directly or view it on GitHub https://github.com/clojure-emacs/cider-nrepl/issues/99#issuecomment-50585333 .

[bbatsov]

I guess one can create an augmented version of the lein repl task that does something similar.

[gtrak]

The biggest problem I see with the approach is I'm not sure if there's a built in classloader we can expect to be available that can load a JAR, in the case of not having dynapath or pomegranate or something, though it looks like since dynapath is full-clojure, you could just send it over the wire too! :-). Not sure if there's any bootstrapping needed above and beyond that, a lein task for this sounds like a great idea.

On Wed, Jul 30, 2014 at 7:39 AM, Bozhidar Batsov notifications@github.com wrote:

I guess one can create an augmented version of the lein repl task that does something similar.

— Reply to this email directly or view it on GitHub https://github.com/clojure-emacs/cider-nrepl/issues/99#issuecomment-50603652 .

[orb]

I would also like to be able to run without the middleware. I hope this stuff can get baked into standard nrepl. We have similar challenges with production use of cider and multiple developers, though our team is small and it's not hard for us to synchronize on versions. We ended up adding cider-nrepl as a proper dependency so as to include the JARs in our deployed uberjar. (and of course, setting the nrepl middleware list in code by copying and pasting from cider-nrepl) I hope locking in a version of a snapshot and the current list of middleware doesn't come back to bite us too hard...

Again - if nrepl is insufficient we really should try and improve nrepl because requiring custom middleware sad option. It's one thing for a toy environment like lightable to require it, but the premier clojure tool should ideally strive to be able to connect to any nrepl, not just ones started up in a magical way.

[bbatsov]

I hope this stuff can get baked into standard nrepl.

Don't think this is going to happen. The purpose of nREPL is to provide a common platform for tool writers to build upon, but different tools have different requirements and you cannot expect the platform to ship everything for everything. I think that it's import for nREPL to have little or no external deps, which contradicts sharply with providing a lot of features out-of-the-box.

There are certainly things that are missing there - most notably form-tracking support in eval (ticket here. Having a mechanism to override the default value rendering wouldn't hurt as well (we could use pretty printing for eval results or display some richer data about some types like SLIME does for Common Lisp).

I hope locking in a version of a snapshot and the current list of middleware doesn't come back to bite us too hard...

Hopefully CIDER 0.7 is around the corner and you won't have to use snapshots anymore.

Again - if nrepl is insufficient we really should try and improve nrepl because requiring custom middleware sad option. It's one thing for a toy environment like lightable to require it, but the premier clojure tool should ideally strive to be able to connect to any nrepl, not just ones started up in a magical way.

CIDER will work with any nREPL even without it's middleware, but in a very limited way. It's impossible to achieve what you're suggesting simply because functionality like completion has always depended on third-party libraries. We always had some implicit deps, but they weren't formalized (stuff work if they're around and blow up otherwise). Embedding huge clojure strings in the Emacs Lisp code is horrible and next to unmaintainable. Now that most of the logic resides in a pure Clojure codebase it's much easier for Clojure devs to extend CIDER, as all the heavy lifting is done there. I think it makes a lot of sense to make extending the tool accessible to the people who're using it. I'm pretty sure that I'm one of the very few CIDER users who knows more about Emacs Lisp than about Clojure. :-)

And there's ClojureScript to consider - we couldn't have supported it properly without our extra middleware.

Btw, there was one surprising effect when we introduced cider-nrepl - vim-fireplace started using it as well. By extracting the logic into some reusable middleware we've made it easy for other similar projects to recycle it.

Here I'll invite the awesome father of nREPL @cemerick to share his thoughts regarding your concerns.

[orb]

The fact that other people are using cider-nrepl points to the idea that what cider-nrepl is should be the common standard set of middleware.

I think what troubles me the most is that up until this point the Clojure repl story has been very good. You could count on the fact that any reasonable clojure dev environment (cider being the undisputed kind and gold standard of clojure dev environments) would be able to connect to any Clojure process that was running running nrepl and you would be able to do almost anything you want.

Now we are starting to lose this, and the clojure experience is degraded as result. The last time I tried to connect to an nrepl without the cider-nrepl middleware I wasn't able to do anything at all. Maybe this has improved recently.

If goal of nrepl has always been to create silos of incompatible nrepls, I'd say that's a flawed plan that doesn't seem to be in the interest of clojure development community. It certainly is great that we can customize that experience and build interesting things, but I think we need a good core set of nrepl functionality that we can count on to be everywhere that nrepl is.

Again - my apologies if any of this discussion here or on twitter has come across in any way negative. I truly appreciate all this work you guys do. I'm just a passionate user who things that nrepl is one of the key selling points of Clojure dev and who sees fragmentation of nrepl as a very bad thing for Clojure.

[gtrak]

I don't think the standardization of cider middlewares is the best path since they're fast-changing and should be kept that way. However, I think it would be awesome if nrepl had some allowances for code-loading/middlewares on an existing nrepl session. In theory, it wouldn't be a big change to eval all the middleware impl clojure code over the wire (like what cider was doing before), and that functionality itself could be implemented as a middleware.

On Fri, Aug 1, 2014 at 12:13 PM, Norman Richards notifications@github.com wrote:

The fact that other people are using cider-nrepl points to the idea that what cider-nrepl is should be the common standard set of middleware.

I think what troubles me the most is that up until this point the Clojure repl story has been very good. You could count on the fact that any reasonable clojure dev environment (cider being the undisputed kind and gold standard of clojure dev environments) would be able to connect to any Clojure process that was running running nrepl and you would be able to do almost anything you want.

Now we are starting to lose this, and the clojure experience is degraded as result. The last time I tried to connect to an nrepl without the cider-nrepl middleware I wasn't able to do anything at all. Maybe this has improved recently.

If goal of nrepl has always been to create silos of incompatible nrepls, I'd say that's a flawed plan that doesn't seem to be in the interest of clojure development community. It certainly is great that we can customize that experience and build interesting things, but I think we need a good core set of nrepl functionality that we can count on to be everywhere that nrepl is.

Again - my apologies if any of this discussion here or on twitter has come across in any way negative. I truly appreciate all this work you guys do. I'm just a passionate user who things that nrepl is one of the key selling points of Clojure dev and who sees fragmentation of nrepl as a very bad thing for Clojure.

— Reply to this email directly or view it on GitHub https://github.com/clojure-emacs/cider-nrepl/issues/99#issuecomment-50903271 .

[cemerick]

I'd +1 nearly everything @bbatsov said.

The current situation where every tool has its own set of nREPL middlewares to support the particulars of its capabilities (e.g. eldoc is great in emacs, irrelevant for intellij, etc) seems like a very good local maximum, especially compared to the situation years ago, when every tool maintained its own network REPL implementation, soup-to-nuts.

There is absolutely a place for standardization to occur, though it's a slow, nontechnical process: tool makers have to eventually converge on a particular set of middlewares (or, preferably, a common set of operations and associated semantics that multiple middlewares can implement). This has been happening for some time, as different tooling ecosystems pool resources to improve particular implementations. I'm definitely not going to promote any of these into nREPL proper, at least not for the foreseeable future: even for things as apparently straightforward as code completion or doc lookup, consensus on what should or shouldn't be offered as a baseline shifts very quickly, often pushed by new/better/different tool offerings. Right now, there's nothing stopping people from moving from one nREPL tool to another with little difficulty, and I don't want to do anything to make that harder.

There is room for an autodiscovery / remote upgrade capability in nREPL. An example implementation of the former is https://github.com/technomancy/nrepl-discover, and there are other sketches of it and remote upgrade floating around. For now, there's nothing stopping anyone from making these tools "included by default", simply by baking them into the user profile, etc. But, I think this is a place where nREPL could bake in some functionality that just about everyone would be happy with that would make further customization work a lot easier.

[bbatsov]

There is room for an autodiscovery / remote upgrade capability in nREPL. An example implementation of the former is https://github.com/technomancy/nrepl-discover, and there are other sketches of it and remote upgrade floating around. For now, there's nothing stopping anyone from making these tools "included by default", simply by baking them into the user profile, etc. But, I think this is a place where nREPL could bake in some functionality that just about everyone would be happy with that would make further customization work a lot easier.

Something similar supported by default would be great.

[bbatsov]

Seems to me that we can close this now.