-
Notifications
You must be signed in to change notification settings - Fork 176
-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to resolve var: cider.nrepl.middleware.trace/wrap-trace #96
Comments
Haven't run into this. Likely something is misconfigured, can't think of anything else that would result in a middleware var going AWOL. |
As of today also seeing this. No config changes on my side. |
I deleted my |
Closing this as unreproducible. |
I got the same issue. The cause was that It's always a good idea to be aware of any library version conflicts in your project's dependency tree. The way to view this is with
In my case, I set a global exclusion in my project such that none of my dependencies would bring in a (potentially different) version of
This is not a bug in cider-nrepl, but users upgrading to Cider 0.7.0 should be aware of the new requirement that their Clojure projects' dependencies must 'peacefully co-exist' with those brought into Clojure's app classloader by |
@malcolmsparks You're spot on. We eventually made the same discovery while investigating a I was a bit surprised that people actually use such tooling libraries in their projects - seems to me that they belong mostly in the realm of development tools. Anyways, we'll try to keep the number of cider dependencies to the bare minimum to avoid such nasty scenarios. |
an other way to solve this is how eastwood does it: see dependency readme. what do you guys think? is that an overkill? makes sense? cc @malcolmsparks |
I definitely feel this is an overkill. Of course, it's also regrettable that a tool like eastwood needs be a project dependency - if it were me doing it, I probably would have made it standalone. |
well, it is basically a lein plugin which makes sense I guess. so you add it as a dependency/plugin in |
You only need the source code to be build an AST. |
I hear you and I am sure you are right. but then I also had a chat with Nicola the other day where he said:
|
Ah, yes. Nicola's quite right, of course. I didn't consider any of those things when I wrote my previous comment. |
so back to the original question, the above said: do you still see this as an overkill for dev tools like |
A couple of years back I tried (and failed) to write a tool like Eastwood to detect redundant ns decls, if you do any significant re-factoring on a Clojure project you end up with lots of these. I didn't realise at the time the difficulty of doing this statically when you have a macro system, so concur with @benedekfazekas. Looking at the current deps tree of cider-nrepl, I'm inclined to anticipate further issues like this one being posted by users, necessitating an FAQ or dedicated blog article to help steer around them. This depends on various factors such as how stable the libraries are, the extent to which cider-nrepl uses new features in them and scope-expansion bringing in more dependencies. These issues may be mitigated if cider-nrepl keeps current with the tools libraries it depends on. Projects that depend on newer versions of these libraries may be doing so because they need new functionality, and so clashes with cider-nrepl will be common if cider-nrepl stagnates. But here's the rub: developers don't like forever updating their core development environment. "If it works, don't fix it" is the mantra here (especially if you code for a living). So I think, on balance, the approach taken by Eastwood is worth future consideration. |
probably this is a bit offtopic now, but working on |
IIRC, Eclipse does a similar thing by prefixing its embedded tools (e.g. On 14 August 2014 13:30, benedekfazekas notifications@github.com wrote:
|
@benedekfazekas Might be useful. I'm not that worried about such problems right now, because as I said earlier, it's quite unlikely that someone would depend directly on That said, I'd love to see a solution that would give us the ability to leverage more 3rd party libs without worrying about the dependency conflicts. |
btw. Almost every project I am involved in developing depends directly on On 14 August 2014 13:38, Bozhidar Batsov notifications@github.com wrote:
|
@malcolmsparks This is the same reason cider uses this library - there's a command to reload your current namespace. Same goes for tracing - we have a tracing command based on it. That's what I meant when I said people used to require those directly, but now don't have to do so. |
Now I understand, thanks for clarification. On 14 August 2014 13:53, Bozhidar Batsov notifications@github.com wrote:
|
It may be worth noting that Clojure itself also does something similar with the ASM library to prevent version conflicts (as do Scala and JRuby) - https://github.com/clojure/clojure/tree/master/src/jvm/clojure/asm |
- so dependencies can be included as source and dependency clashes can be avoided with projects being refactored
Hi there,
As of last Friday myself and a couple others on my team have been experiencing this issue with cider-nrepl. Is this a known issue? I get the following stacktrace if I try to start a repl:
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: cider.nrepl.middleware.trace/wrap-trace in this context, compiling:(/private/var/folders/gx/q3y1xf6x60s78zlp1g249blr0000gn/T/form-init2361553506959370289.clj:1:6479)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.analyze(Compiler.java:6406)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.analyze(Compiler.java:6406)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.access$100(Compiler.java:38)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6050)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.analyze(Compiler.java:6406)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.eval(Compiler.java:6700)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve var: cider.nrepl.middleware.trace/wrap-trace in this context
at clojure.lang.Util.runtimeException(Util.java:221)
at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:659)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
... 33 more
REPL server launch timed out.
This is while including cider with the following in our profiles.clj: [cider/cider-nrepl "0.7.0-SNAPSHOT"]
Thanks,
Tom
The text was updated successfully, but these errors were encountered: