Migration to cider nrepl

First of all: the following is not a commitment to migrate to cider-nrepl. It's the result of the exploration of the opportunity to migrate to it. With that said, there would be huge benefits for everybody should the migration be done, so it is with a great excitement that I start working on this.

Benefits of moving to cider-nrepl

• unified repl-based tooling back-end between emacs, vim, ccw, etc.
• good for codebase stability
• good for cross IDE users
• good for healing my NIH syndrom
• good for my time: having just to "integrate" some features in CCW and not have to re-implement it again is good (there are already lots of features implemented in cider-nrepl that are just not present in CCW)
• good for Clojure external visibility: "look ma, those guys are able to talk to each other and intelligently share work"

Risks and problems moving to cider-nrepl

The following will need to be addressed in order to be mitigated or removed, before confidently switching CCW's repl backend from ccw.server to cider-nrepl.

Losing existing features

• cider-nrepl does not provide fuzzy auto-completion as ccw does currently ''[TODO]''
• cider-nrepl does not display some.namespace/bar or some-alias/bar as a completion candidate when searching for bar (is it possible in ccw currently? is this a sub-case of the fuzzy auto-completion?).

Weakening CCW stability

• cider-nrepl is a moving target, as was leiningen a while ago. The possibility that the user provide as a leiningen plugin a version of cider-nrepl incompatible with CCW is not nil.

Preventing some class of users to use CCW

• cider-nrepl requires a bunch of dependencies to work, whereas ccw.server requires none. The probability that there is a conflict between cider-nrepl dependencies and the user project dependencies is quite high at the moment.

Locking CCW in a nREPL world

cider-nrepl is currently tightly coupled to nrepl. It will need some refactoring to extract the nrepl-independent code so it can be used with the new (as of 2015-03-30) socket-based Clojure REPL. On the contrary, ccw.server with its single-namespace+no dependency features is almost a perfect match as a library for a socket-based Clojure REPL.

To the extent that it could be possible to not require anything special from the user, with socket-based REPLs: ccw.server could easily be sent over the socket in the connection dedicated environment.

Solutions to the above problems

The following is a list of ideas to mitigate or remove the problems seen in the current state.

How not to lose existing features

Fuzzy completion

I don't think cider-nrepl authors would be opposed to work on this or accepting patches, as long as it does not break anything, and the patches are small enough to be digested one bit at a time.

Fixing cider-nrepl dependencies

This is already a known problem in the community. Even if the number of dependencies seems quite high (but I haven't looked closely at it), and may be reduced somehow, it is clear that there will always remain external dependencies.

Having the possibility to embed all dependencies with a cider.dep kind of prefix would be an interesting solution. It would prevent almost all conflicts with user projects.

The burden then comes back to cider-nrepl developers:

• without proper tooling, it becomes harder to update cider-nrepl dependencies
• it will be weird to have cider.dep kind of prefix in front of dependencies they are used to call directly in other projects they may work on.

But with proper tooling, the development codebase may be written as normal, and only when packaging cider-nrepl could the codebase and the dependencies be rewritten as proposed above.

• Dunno if such a tool already exists for clojure codebases
• Dunno if such a tool, if it exists, is stable enough
• Dunno if this can work when dependencies rely themselves on java class-based dependencies.

Staying open to socket-based REPLs

It's certainly possible to refactor cider-nrepl so that the core part is decoupled from the nrepl part.