Clojurians Log v2

When I use leiningen to build an uberjar, it will compile each of my namespaces and when it gets to where I use core.cache, it will fail with

Syntax error compiling at (clojure/core/cache/wrapped.clj:53:25).
Syntax error compiling at (clojure/core/cache/wrapped.clj:53:25).
No such var: c/through-cache

> dependencies issues leading leiningen to use both core.cache 0.8.2 and 0.6.5 a bad dep might bring in a duplicate lib because it precompiled, but lein never puts the same lib on the classpath twice

I think your real issue is that it's not using the version you want, check out the output of lein deps :tree

that will show conflicts in dep versions, and which versions it's picking, and why

There’s also “lein deps :plugin-tree” in case you have plugins brining in dependencies

@regen oops, forgot to tag you above

I checked lein deps :tree and oddly core.cache showed up only once for 0.8.2, which was the direct dependency.

I tried plugin-tree as well, and it doesn't pop up there.

Before this I had a very confusing problem where [yogthos/config "1.1.7"] was a direct dependency, and then I had another dependency which had [yogthos/config "0.9"] as a direct dependency. When I built the uberjar, it would use version 0.9.

I cannot make sense of why that would happen. It's supposed to use the version closest to root right?

I make sure to clean all the leiningen dirs so only the source code remains in the project directory, but I'm still paranoid there's some cache I'm missing. I've also tried clearing .m2 but it will still download both those versions.

here's a thing you can try: use io/resource to see if the ns is pulled from an unexpected place:

user=&gt; (<http://clojure.java.io/resource|clojure.java.io/resource> "clojure/core.clj")
#object[java.net.URL 0x7b02e036 "jar:file:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar!/clojure/core.clj"]

there's a similar trick for checking if it came from a precompiled init...

user=&gt; (<http://clojure.java.io/resource|clojure.java.io/resource> "clojure/core_init.class")
nil

or you can look at classpath and check for weird entries

user=> (System/getProperty "java.class.path")
"src:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/home/justin/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/home/justin/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar"

Thanks. I'll give that a try for "clojure/core/cache/wrapped.clj" once I've changed the source code to make it run.

you can also start a repl from an uberjar, even if your own code in your jar is broken:

$ java -cp target/foo-0.1.0-SNAPSHOT-standalone.jar clojure.main -e '(<http://clojure.java.io/resource|clojure.java.io/resource> "clojure/core.clj")'
#object[java.net.URL 0x28d6290 "jar:file:/home/justin/foo/target/foo-0.1.0-SNAPSHOT-standalone.jar!/clojure/core.clj"]

Wow. Some wizardry in here!

and similarly for the classpath lein builds by default:

$ java -cp $(lein cp) clojure.main -e '(<http://clojure.java.io/resource|clojure.java.io/resource> "clojure/core.clj")'
#object[java.net.URL 0x4e517165 "jar:file:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar!/clojure/core.clj"]

@regen I learn well from pain, and the times I've had to care about these things have often been painful

Damn. I guess it's time for me to go through the pain as well...

the nice thing is that clojure is full of a bunch of great tools that can tell you what's wrong with a clojure codebase / built artifact

the C or even Java equivalents of this debugging are much weirder

I can't spot anything immediately wrong, but I'll try again with these newfound tools tomorrow as it's close to midnight here.