oddity after upgrading many things today, including cider. cider-version is a variable defined in ‘cider.el’. Its value is "0.18.0-snapshot"

I run cider-jack-in-clj&cljs, and find a .clj file in the project, and then do ^C^K to reload, and it looks like it's trying to feed it to clojurescript, rather than clojure

did something change in this regard, am I doing it wrong, or am I finding bugs?

Sorry for the problems people using extra middleware encountered, but I simply can’t run after everyone and fix everything in each project. I’ve notified the maintainers of both sayid and refactor-nrepl of what they need to do. It’s really simple. If you’re frustrated by this, you have no idea how frustrating it has been for me to coordinate the nREPL switch over a dozen projects. 🙂

@bozhidar No need to apologise. You are doing great work that is very much appreciated. A few hiccups along the way are to be expected.

Anyways, I’ve just push this to refactor-nrepl https://github.com/clojure-emacs/refactor-nrepl/commit/548ee3ebc173b06417d115a5f8e2748521632a60

I don’t have deploy rights there, so I can’t issue an updated snapshot myself.

I also opened https://github.com/bpiel/sayid/pull/40

So I quite literally went and fixed this everywhere. 🙂

@pauld Yeah, they are sort of broken right now. Hopefully someone will cut new releases really soon now that the necessary changes for them have been made.

@bozhidar I may only imagine how frustrating those things can be. As @soulflyer mentioned, no need to be sorry about it. we are all really grateful for your tremendous work, even if some dependency blows up sometimes. and by the way, it was good to hear you in latest defn podcast 🙂

Thanks!

@bozhidar the find-ns trick turns out is pretty unreliable and breaks as soon as the user has a user.clj. https://github.com/thheller/shadow-cljs/issues/360

things would be much easier if there was an actual cider-nrepl release with 0.4 support

any idea when that will be done?

@thheller The 0.18-SNAPSHOT support 0.4 in exactly the same manner. 😄

For me it’s very easy to cut a release with a hard dep on 0.4, but this will mean that it will no longer be usable with lein repl and boot repl.

> things would be much easier if there was an actual cider-nrepl release with 0.4 support

Btw, how would that help exactly? And are you suggesting that I just have a hard dep on 0.4 instead of the current conditional trick (which seems to work for most users).

@bozhidar the problem right now is that I can't tell which version of cider-nrepl the user is going to use. I need to spin up the correct nrepl server version otherwise since things go boom otherwise.

so if I start the 0.4 version the non-snapshot versions break. I'd be nice if I could tell people to upgrade to 0.18 but I do not like recommending snapshot versions

Got it. I’ll likely cut a release tomorrow and finally break the cycle of lock-stepping the cider-nrepl and cider versions.

I think I found a solution. Although I thought that the last time time. This time I'm going to check which nrepl namespace the cider.nrepl is actually referencing and start the server accordingly

Humm….. I have a small project which uses deps.edn … it seems like cider correctly pulls in the jar dependencies, but doesnt do the “path” correctly. Is this a known limitation??

$ ls
b.clj		c.clj		deps.edn
$ cat deps.edn
{ :paths ["."] }
$ cat b.clj
(ns b)
(defn beep []
  (println "beep"))
$ cat c.clj
(ns c
  (:require b))
(defn -main [& args]
  (b/beep )
  (println "I got" args))
$ clj -m c
beep
I got nil

but when I cider-jack-in from the c.clj buffer, eval of “(ns c (:require b))” always yields, “Could not locate b__init.class or b.clj on classpath.”