Unable to resolve var: cider.nrepl.middleware.trace/wrap-trace

[clojure-emacs]

Unable to resolve var: cider.nrepl.middleware.trace/wrap-trace

[semperos]

I deleted my ~/.m2/repository/cider/cider-nrepl folder and did a lein clean on the project in question, which cleared this up.

[bbatsov]

Haven't run into this. Likely something is misconfigured, can't think of anything else that would result in a middleware var going AWOL.

[semperos]

As of today also seeing this. No config changes on my side.

[bbatsov]

Closing this as unreproducible.

[malcolmsparks]

I got the same issue. The cause was that cider.nrepl.middleware.trace uses a var (trace/traced?) of org.clojure/tools.trace that was introduced since tools.trace-0.7.3. Any libraries in your project that depend on 0.7.3 (or earlier) of tools.trace may cause a version conflict. In my case, I was using a version of Liberator (0.11.x) that depended on tools.trace 0.7.3 (the latest version of Liberator, 0.12.x, appears to have fixed this).

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

lein deps :tree

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 tools.trace :-

:exclusions [org.clojure/tools.trace]

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 cider/cider-nrepl. Again, it's a good idea to check with lein deps :tree to ensure you know about any conflicts that exist.

[bbatsov]

@malcolmsparks You're spot on. We eventually made the same discovery while investigating a tools.namespace related bug.

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.

[benedekfazekas]

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

[bbatsov]

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.

[benedekfazekas]

well, it is basically a lein plugin which makes sense I guess. so you add it as a dependency/plugin in dev scope. and it does need the project's dependencies otherwise it is quite difficult to build a meaningful AST for the project namespaces if I understand it right...

[bbatsov]

and it does need the project's dependencies otherwise it is quite difficult to build a meaningful AST for the project namespaces if I understand it right...

You only need the source code to be build an AST.
A static analyzer should not care about a project's dependencies (I should know as I wrote one of the popular static analyzers for Ruby) - it's called static for a reason and the reason it only analyzes the AST (generally in the context of a single file), without regard for library details.

[benedekfazekas]

I hear you and I am sure you are right. but then clojure.tools.analyzer and clojure.tools.analyzer.jvm is not a static analyzer in that sense (used by eastwood) I assume. In fact eastwood analyze+eval your code when linting it.

I also had a chat with Nicola the other day where he said:

At the moment there's no good way to get a meaningful AST out of a whole
namespace without evaluating each clojure form as you go, since anything
could happen at macroexpansion time, var interning, dynamic class
generation, local bindings injection etc. and I honestly doubt there
will ever be, this is a limitation imposed by the semantics of clojure
itself.

[bbatsov]

Ah, yes. Nicola's quite right, of course. I didn't consider any of those things when I wrote my previous comment.

[benedekfazekas]

so back to the original question, the above said: do you still see this as an overkill for dev tools like cider-nrepl eastwood, refactor-nrepl etc?

[malcolmsparks]

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.

[benedekfazekas]

probably this is a bit offtopic now, but working on refactor-nrepl and facing similar problems I was thinking if I should go the same way as Eastwood perhaps generalising the solution as a leiningen plugin or such. would be interested in your opinion specially @bbatsov and @malcolmsparks

[malcolmsparks]

IIRC, Eclipse does a similar thing by prefixing its embedded tools (e.g.
Jetty) with org.eclipse. Any ns renames would have to be tested, because a
library might make assumptions as to its namespaces. The lein plugin would
be useful, because this renaming process would have to be repeated on every
update of a library dependency. Renaming namespaces feels like a bit of a
hack, but I can't think of another viable approach.

On 14 August 2014 13:30, benedekfazekas [email protected] wrote:

probably this is a bit offtopic now, but working on refactor-nrepl and
facing similar problems I was thinking if I should go the same way as
Eastwood perhaps generalising the solution as a leiningen plugin or such.
would be interested in your opinion specially @bbatsov
https://github.com/bbatsov and @malcolmsparks
https://github.com/malcolmsparks

—
Reply to this email directly or view it on GitHub
#96 (comment)
.

[bbatsov]

@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 tools.namespace and tools.tracing as those are clearly targeting development tools. Right now some people have them in their profiles because previously they've cooked custom elisp that used them, but I doubt this will be an actual issue after cider 0.7 (as the custom code is now redundant).

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.

[malcolmsparks]

btw. Almost every project I am involved in developing depends directly on
tools.namespace due to
http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded so
there's that. Plus tools.trace is very useful at times, so many of my
projects use that too. Due to the way Clojure works, we can't use
classloaders to provide isolation between dev tools and runtime (not
necessarily a bad thing) but its a problem here.

On 14 August 2014 13:38, Bozhidar Batsov [email protected] wrote:

@benedekfazekas https://github.com/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 tools.namespace
and tools.tracing as those are clearly targeting development tools. Right
now some people have them in their profiles because previously they've
cooked custom elisp that used them, but I doubt this will be an actual
issue after cider 0.7 (as the custom code is now redundant).

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.

—
Reply to this email directly or view it on GitHub
#96 (comment)
.

[bbatsov]

@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.

[malcolmsparks]

Now I understand, thanks for clarification.

On 14 August 2014 13:53, Bozhidar Batsov [email protected] wrote:

@malcolmsparks https://github.com/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.

—
Reply to this email directly or view it on GitHub
#96 (comment)
.

[cichli]

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