Fork me on GitHub
#leiningen
<
2021-04-14
>
herald15:04:31

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
Earlier I had some dependencies issues leading leiningen to use both core.cache 0.8.2 and 0.6.5, and the latter is missing through-cache. After experimenting with exclusions, I managed to stop leiningen from downloading version 0.6.5. Right now I only get 0.8.2 in my .m2 folder, and I have also cleaned my entire project directory, so there should be no target/classes leftover; just source code. Still I'm getting the same error everytime. Is there something I've missed?

noisesmith18:04:33

> 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

noisesmith18:04:15

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

noisesmith18:04:44

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

dpsutton18:04:52

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

noisesmith18:04:14

@regen oops, forgot to tag you above

herald21:04:31

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

herald21:04:25

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

herald21:04:49

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.

herald21:04:34

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

herald21:04:19

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.

noisesmith21:04:41

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

user=> ( "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"]

noisesmith21:04:24

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

noisesmith21:04:00

user=> ( "clojure/core_init.class")
nil

noisesmith21:04:24

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"

herald21:04:42

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

noisesmith21:04:34

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 '( "clojure/core.clj")'
#object[java.net.URL 0x28d6290 "jar:file:/home/justin/foo/target/foo-0.1.0-SNAPSHOT-standalone.jar!/clojure/core.clj"]

herald21:04:52

Wow. Some wizardry in here!

noisesmith21:04:10

and similarly for the classpath lein builds by default:

$ java -cp $(lein cp) clojure.main -e '( "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"]

noisesmith21:04:33

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

herald21:04:20

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

noisesmith21:04:13

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

noisesmith21:04:35

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

herald21:04:14

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