@cfleming That’s the first time I see such an error. That new var is simply a way for tools like Lein to print properly the nREPL url now that it has more transports (before all tools had hardcoded nrepl://
). The var was actually added in nREPL 0.5.
https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/transport.clj#L220
What’s his piggieback version? Your user should be on 0.4 for things to work properly.
@bozhidar Actually, it’s not the first time you’ve seen it :-): https://github.com/eraserhd/rep/issues/1
I’m waiting for some details on his setup, such as piggieback version.
I’ll let him know that 0.4 is what he should be using.
> https://github.com/eraserhd/rep/issues/1 It’s different here - he injected an older version of nREPL when Lein expected a newer one. I think you mentioned your user was on 0.6, that’s why I can imagine how this can be missing.
Yeah, I don’t know much about his setup - he just said it’s a CLJS project and he gets the error at startup. But I think the fact that Cursive has upgraded the nREPL it uses is misleading, since if he’s using lein that version won’t be used anyway, it’ll be whatever lein is using.
I suspect that upgrading Cursive will have caused him to use a later leiningen, which is incompatible with whatever piggieback he’s using, but I’m not sure yet.
Awesome, problem was fixed by upgrading nREPL and Piggieback.
Great!
How does Cursive start nREPL itself, btw? It doesn’t use any build tool and sorts out the projects deps itself?
That’s used when someone wants a REPL in a project that’s not managed by something like lein that will start a REPL for you. So things like Gradle or Maven, or a manually configured project. Then, right, Cursive will use the IntelliJ classpath and just add nREPL to it, and then inject an init script which starts the server.
Understood. That sounds neat!
Yeah, I use it a lot since I use Gradle a fair bit for mixed Clojure/Kotlin projects (Cursive itself, in particular).
I haven’t used Gradle since my days as a Java programmer. 🙂