leiningen

N.B. The maintainers are on #leiningen on Libera chat IRC. Go there for direct support/bug reports.
uosl 2021-04-14T15:50:31.058700Z

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?

2021-04-14T18:03:33.060600Z

> 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

2021-04-14T18:04:15.061200Z

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

2021-04-14T18:04:44.061600Z

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

dpsutton 2021-04-14T18:08:52.062700Z

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

2021-04-14T18:10:14.063Z

@regen oops, forgot to tag you above

uosl 2021-04-14T21:33:31.063700Z

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

uosl 2021-04-14T21:36:25.064400Z

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

uosl 2021-04-14T21:37:49.065400Z

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.

uosl 2021-04-14T21:38:34.065900Z

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

uosl 2021-04-14T21:39:19.067200Z

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.

2021-04-14T21:39:41.067400Z

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"]

2021-04-14T21:40:24.068Z

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

2021-04-14T21:41:00.068300Z

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

2021-04-14T21:43:24.069400Z

or you can look at classpath and check for weird entries

user=&gt; (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"

uosl 2021-04-14T21:43:42.069800Z

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

2021-04-14T21:44:34.070500Z

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"]

uosl 2021-04-14T21:44:52.070700Z

Wow. Some wizardry in here!

2021-04-14T21:45:10.071100Z

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"]

2021-04-14T21:45:33.071700Z

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

uosl 2021-04-14T21:46:20.072Z

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

2021-04-14T21:47:13.072700Z

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

2021-04-14T21:47:35.073200Z

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

uosl 2021-04-14T21:54:14.074Z

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