Add jack-in support for ClojureCLR

[rene-descartes2021]

Adds jack-in support for ClojureCLR.

Only changes are in the CIDER (elisp) side.
No changes to the cider-nrepl (Clojure) side are made.

Allows jacking into a ClojureCLR nREPL server clojure/clr.tools.nrepl [1] with CIDER.

clojure/clr.tools.nrepl is at present a port of babashka/babashka.nrepl [2] to ClojureCLR. Which might later change to a port of nrepl/nrepl [3] once that port to ClojureCLR is working.

So, at present jacking into ClojureCLR nREPL server this PR is set to is just like jacking into a Babashka nREPL server. Default middleware are in those repos not in cider-nrepl. W.r.t. those I see that middleware can be specified/added-to via the :xform parameter, but at present the jack in for Babashka doesn't support that so I didn't add it for the jack into ClojureCLR. I guess someone might want to do that with CIDER?

Once the nrepl/nrepl port to ClojureCLR is working (in the subdir of clojure/clr.tools.nrepl) then better integration with CIDER can be considered, including adapting cider-nrepl to ClojureCLR. That's my understanding. I guess that's the direction things are going.

Related: #3361

Problems with this PR:

For unknown reasons eventually the sync fails and things don't seem to work.

At that point reconnecting via CIDER commands doesn't seem to work. Hadn't diagnosed what to do about this, I've come from dotnet-land wanting to use Clojure: I've never used CIDER before so I don't know what to expect. Probably user-error I guess.

EDIT: Maybe spacing in the docs might be wrong. I eyeballed the formatting. I guess linting might complain if I got that wrong.

My use-case/motivation:

For ClojureCLR I think the trend is to use inf-clojure with the socket REPL server, not Cider with an nREPL server. For Calva the vscode plugin for Clojure, looks like they've looked into using clojure/clr.tools.nrepl (nREPL) for ClojureCLR but I don't use vscode.

I'm using Doom emacs and the clojure module uses CIDER not inf-clojure and I didn't want to deal with remapping hotkeys & other configuration. So I wanted to explore using clojure/clr.tools.nrepl as-is with CIDER.

I thought to submit this PR as a basis for others to continue in the effort using & improving CIDER with ClojureCLR.

---

Before submitting the PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

• The commits are consistent with our contribution guidelines
• You've added tests (if possible) to cover your change(s)
• All tests are passing (eldev test)
• All code passes the linter (eldev lint) which is based on elisp-lint and includes
  • byte-compilation, checkdoc, check-declare, packaging metadata, indentation, and trailing whitespace checks.
• You've updated the changelog (if adding/changing user-visible functionality)
• You've updated the user manual (if adding/changing user-visible functionality)

Thanks!

If you're just starting out to hack on CIDER you might find this section of its
manual extremely useful.

[rene-descartes2021]

EDIT: I decided to add an integration test to test/integration/integration-tests.el. I've already added CI support in .github/workflows/test.yml.

Manual test will be like:

1. Install dotnet
2. Install ClojureCLR tools:

dotnet tool install --global Clojure.Main
dotnet tool install --global Clojure.Cljr
# add dotnet tools path to PATH
export PATH="$PATH:$HOME/.dotnet/tools"
# test cljr on cli
cljr
# if tool fails to run and dotnet complains about missing version then use env variable
export DOTNET_ROLL_FORWARD="major"

3. If on Linux then make a deps-clr.edn file as workaround for upstream issue in cljr:
EDIT: Fixed upstream problem.
4. Test jack-in in emacs:

emacs some.clj
# M-x cider-jack-in-universal

[rene-descartes2021]

Ok I added an integration test but it fails with:
error: (error ":cider-itu-poll-until-errored :timed-out-after-secs 60 :waiting-for (cider-repls 'clr nil)")

I guess the timings could be pruned a bit but I'm not sure what is going wrong- I essentially copied over the babaska integration test due to same underlying stuff, so I'd expect it to work. Jacking in with emacs works!

Also in the integration test just for clr I get a prompt labeled "Project:", once I press enter it continues. I'm not sure what is going on there I shouldn't have to interact.

[rene-descartes2021]

Updated version in GitHub workflow to what would work on Linux, forgot to update that.

[bbatsov]

Sorry for the radio silence here - I'll take a closer look soon.

[rene-descartes2021]

I apologize maybe I should have left it as WIP until I figured things out better and got that test working. Slowly learning things and tooling didn't work so started there. I enjoy working on tooling. This stuff outside my background knowledge for now though.

Just recently figured out how to jack-in with CIDER to a java project with just pom.xml files and built with mvn install. Had to manually populate deps.edn files. Anyway slowly figuring things out.

Well I'll fix it eventually if no one else gets to it so no worries.

[bbatsov]

Doesn't it have any tagged releases?

[rene-descartes2021]

Yes it does that's what I tried at first but Clojure isn't designed that way for git dependencies. For maven just specifying :mvn/version works, but for a git dep if only :git/tag is specified it errors and still requires :git/sha anyway. So rather than have end user having to specify two things to version it I just elected for the full SHA.

Dunno why it was designed that way, at a glance I'd expect the git tag should be sufficient, but I guess maybe the lack of trust is from the possibility of a bad actor in a supply chain attack changing the tag in the repo? Always specifying the SHA at least in part should mitigate that:
https://clojure.org/reference/deps_edn#deps_git_tag

[bbatsov]

I wonder if we should used the more descriptive naming "clojure-clr-cli" (or the shorter "clr-cli") instead of just "clr" here, in case at some point we want to add a different way to jack in for Clojure CLR projects. Although, I guess that's somewhat unlikely.

[rene-descartes2021]

I wonder if we should used the more descriptive naming "clojure-clr-cli" (or the shorter "clr-cli") instead of just "clr" here,

So cider-clojure-clr-cli-command in full? Anywhere else? I wasn't really sure how to name things I just tried to follow any patterns I could make out.

in case at some point we want to add a different way to jack in for Clojure CLR projects.

A different way being for Arcadia? That makes sense I think. I personally don't use Unity. Looking around in their issues/PRs I think they've made do just connecting with CIDER manually.

From what I see the commercial support for Arcadia collapsed and they suggested someone else fork it and maintain it.

Looking at the 3 public forks active on GitHub after Arcadia's last commit, they didn't last more than a year, and all had some nREPL changes/fixes [1][2][3].

Well that's a tangent just exploring ideas.

Maybe instead the features within the Arcadia fork of ClojureCLR will get de-fragmented back in/around ClojureCLR by a motivated person(s), I think that would be the best path rather than forking Arcadia... in their videos they described their rationale for the fork and I think it makes sense now to de-fragment. But I wouldn't worry about it till a motivated person shows up and comment.

So I won't worry about supporting a different way to jack into ClojureCLR or a variant of it. Upcoming Clojure LLVM/C++ dialect Jank might better suit their Unity and performance use-case more anyway... or maybe not, I'm not sure.

[bbatsov]

Also in the integration test just for clr I get a prompt labeled "Project:", once I press enter it continues. I'm not sure what is going on there I shouldn't have to interact.

I think that's because clojure-mode and clojure-ts-mode have to add support for deps-clr.edn at they are looking only for deps.edn currently.