Common Tooling library

[volrath]

By Common Tooling I refer to all tooling features that can be shared and reused by UNREPL clients.

In slack @pesterhazy and I were discussing on the best way to accommodate for this. Current options on the table are:

1. Mono repo: React style, they have react, react-server, react-dom, ... all in the same REPL.
2. Separate repo: each client would be responsible to consume this repo, either by including it as a jar file or as a submodule/subtree.

Currently we lean to the second option. This repo/library should be as thin as possible in term of dependencies.

Dependencies should be 'shaded' at build/release time with something like MrAnderson (see also https://github.com/Unrepl/unravel/issues/64)

Clients may also have to shade their inclusion of this library.

[SevereOverfl0w]

I feel strongly about preferring 2 over 1.

A clojure tooling library should be agnostic to anything except clojure & various hosts. Unrepl the protocol is designed such that the kind of hacks present in cider-nrepl to iron over bencode limitations are not necessary.

I think the basis for this library should be cider-nrepl, as it's overall a very solid library. It's fairly (but not perfectly) well separated in terms of util and bencode adaptation. There's a lot of gold in there.

Dependencies are a minor concern due to the shading. Although size is still a factor of course. This is the decision made by cider-nrepl itself.

[volrath]

I forgot to mention cider-nrepl, but I 100% agree with @SevereOverfl0w that there's a lot of great things in there and maybe even working on splitting cider-nrepl into two libraries could benefit everyone, as @bbatsov has stated before.

My comment on dependencies is just related to size. Shading is a must :)

[bbatsov]

Well, as a said before - it's not even a lot of work. Someone just has to find the time to do sit down, do it and write some documentation. Obviously the process can be gradual and we can move things gradually there. The most common things can go to this new library, the more nuanced can stay.

Btw, there's also a lot of gold in https://github.com/clojure-emacs/refactor-nrepl

I even have a cool name in mind for such a shared library - orchard :D

If everyone agrees with such a course of action I can even create one placeholder repo for this. Ultimately it seems to me that regardless of the communication protocol, the concerns you end up in the end are pretty much the same. That's well evidenced by the fact that a lot the code in the early days of CIDER came straight from swank-clojure - I guess few people remember that things like the original completion clojure-complete and the Clojure inspector came pretty much straight from there.

Dependencies are a minor concern due to the shading. Although size is still a factor of course. This is the decision made by cider-nrepl itself.

Size is really an issue only if you decide to eagerly load everything, which generally doesn't make sense.

[bbatsov]

I also forgot to mention https://github.com/clojure-emacs/cljs-tooling - another library we've created to support ClojureScript in CIDER. It's completely cider-agnostic by default. Not sure how exactly do you handle completions and stuff in unrepl, so this might also be useful.

[pesterhazy]

For future reference, some pointers to CIDER's source code that could be useful:

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/info.clj#L87

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/complete.clj

[bbatsov]

A small progress update - https://github.com/clojure-emacs/orchard is steadily growing and growing. A lot of functionality was moved from cider-nrepl there already, and things are looking good overall. Now it's time to polish the API and write some docs. 😉

[bbatsov]

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/complete.clj

We're still debating what exactly to do about it, as it just a thin wrapper over compliment and cljs-tooling, and there's not much to extract really. We'll likely move cljs-tooling to orchard, though.

[mauricioszabo]

I'm trying something here: https://github.com/mauricioszabo/repl-tooling

The difference is that I'm using ClojureScript to target Atom (and VSCode, and NeoVIM, etc), but so far I'm not having too much success in wrapping things. Also, my approach is a little different (I'm trying to send/receive commands, support break, refactor things, wrap middlewares in socket REPL, etc)

[bbatsov]

@mauricioszabo We've got a counter-party to orchard for ClojureScript - https://github.com/clojure-emacs/cljs-tooling It supports self-hosted Clojure since version 0.3, so you might also take a look at it.

I'm not sure what the aim of your project is exactly, but I'm reasonably sure that we've covered at least the basics with the libraries we've developed around CIDER so far.

[mauricioszabo]

@bbatsov Ok, I've added a README in my project to explain better what I want to do with it. But mostly, I want a library to work as an UNREPL client, or Socket REPL (in Clojure, ClojureScript, Lumo, Plank, etc) client so I can have a base lib to integrate in any editor.

I've looked at cljs-tooling and I'll probably use it for AutoComplete and other things (one of the targets of the project is to auto-detect which REPL feature we can use, so for instance, if it detects it's on Clojure and Compliment is present, it'll use it as autocomplete; if it detects it's on Lumo, it'll use Lumo's autocomplete, and so on).

It's still on it's infancy, but so far I'm able to connect Atom (my editor of choice) in a REPL, send a command, capture its output and render in a view with Reagent. Next, I'll try some tooling with NeoVIM.