Skip to content

Conversation

rene-descartes2021
Copy link

@rene-descartes2021 rene-descartes2021 commented Sep 2, 2025

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.

An single upstream problem with the clr.core.cli (cljr):

  • An issue on Linux, not MS Windows.
  • Currently cljr -Sdeps '{:deps {io.github.clojure/clr.tools.nrepl {:git/tag "v0.1.2-alpha2"}}}' -X clojure.tools.nrepl/start-server! doesn't work to jack in the clr.tools.nrepl dependency due to a problem in current ClojureCLR cljr not reading the -Sdeps parameter AFAIK.
  • That dependency does work if it's added to a deps-clr.edn file which is how I use it.
  • Eventually that CLI problem on Linux will get fixed. I have that jack-in dependency stuff in this PR under the premise it'll eventually work on Linux- should work on MS Windows.

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
  • 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 rene-descartes2021 force-pushed the clojure-clr-jack-in branch 2 times, most recently from 8766a70 to d6449a6 Compare September 4, 2025 23:48
@rene-descartes2021 rene-descartes2021 marked this pull request as ready for review September 5, 2025 00:59
@rene-descartes2021 rene-descartes2021 marked this pull request as draft September 5, 2025 15:39
@rene-descartes2021
Copy link
Author

rene-descartes2021 commented Sep 6, 2025

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"
  1. If on Linux then make a deps-clr.edn file as workaround for upstream issue in cljr:
{
  :deps
    {io.github.clojure/clr.tools.nrepl {:git/tag "v0.1.2-alpha2" :git/sha "a58009f"}}
}
  1. Test jack-in in emacs:
emacs some.clj
# M-x cider-jack-in-universal

Rather than do a manual test, I now see that there are "integration tests" which test the integration of CIDER with "project tools", like bb, shadow-cljs, etc., in test/integration/integration-tests.el.

Should I make one a part of this PR? I think the Hacking with CIDER doc says I ought to.

I see some project tool setup is done for CI in .github/workflows/test.yml.

Currently juggling where in my mind where too install dotnet, and the ClojureCLR tools. In both places? dotnet in test.yml, and the ClojureCLR tools in tests.el?

For dotnet core thankfully install doesn't require administrative privileges, can just untar into $HOME/.dotnet then add to the PATH.

I see that for the shadow-cljs integration test in tests.el it shells out to an npm install on a json file. I guess that's where I should analogously put the ClojureCLR tool install?

Well, let me know what makes sense. I don't have java installed an eldev test had no failures for me so... well I don't understand everything going on here quite yet. Oh I see now the integration tests don't run by default but can be ran by eldev test --test-type integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant