We have a strange problem where clj-kondo keeps warning us that medley.core/greatest-by and medley.core/least-by don't exist. Details in ๐งต
Here's an example:
clj-kondo --lint src/matnyttig/import/tilsynsloop.clj
src/matnyttig/import/tilsynsloop.clj:4:14: warning: namespace cljc.java-time.local-date-time is required but never used
src/matnyttig/import/tilsynsloop.clj:10:34: error: Unresolved var: greatest-by
src/matnyttig/import/tilsynsloop.clj:10:46: error: Unresolved var: least-by
linting took 49ms, errors: 2, warnings: 1
See namespace form in screenshotThe red line is lsp complaining about the same thing via kondo
are you using :refer-all maybe?
No, just refer, see screenshot
clj-kondo --lint src/matnyttig/import/tilsynsloop.clj
src/matnyttig/import/tilsynsloop.clj:125:25: error: Unresolved var: medley.core/least-by
src/matnyttig/import/tilsynsloop.clj:664:36: error: Unresolved var: medley.core/greatest-by
linting took 87ms, errors: 2, warnings: 0
It complains even without the referah ok. can you see if there is a cache file in
.clj-kondo/.cache/v1/cljc/medley.core.transit.json or so?and then send it here?
Will do. I cleaned out .clj-kondo to verify that this problem persisted btw - it did.
do you perhaps have another version of medley on the classpath accidentally? medley changed organizations which is a likely cause of having the same library on the classpath twice.
dev.weavejester/medley
it used to be medley/medley I think
so print your deps tree and see if there's another medley in there
Yes, I also suspected multiple medley's on the classpath ๐
But there was only one
clojure -X:deps tree | grep medley
dev.weavejester/medley 1.9.0
is this the same classpath that clojure-lsp uses? it might combine multiple from shadow-cljs etc too
Hmm, good question
I verified the problem without lsp though - using clj-kondo on the CLI. Not sure what deps it is using?
I'm pretty sure this is the issue. I'll bet you a beer on it next time we meet on a conference ;)
I don't mind receiving a beer ๐
it doesn't use any deps unless you tell it to lint a classpath. if you just wipe the .clj-kondo/.cache then it won't complain about this
so try to find out which classpath clojure-lsp uses
Yes, verified that the warning goes away without the .cache dir
Any hints on how to find out what classpath lsp uses? ๐
I'm trying to figure out that myself :)
does it have a command line option for this?
I don't really know anything about it, @magnars just made sure it works in my Emacs ๐
ah lsp-clojure-server-info-raw in emacs
this will print the classpath in some buffer
in *Messages*
hah, look at that
A wild Medley 1.4.0 appears
๐ป
๐
FWIW, I said the same thing to @magnars earlier: "There has to be two medleys on the classpath"
This reminds of how nrepl-refactor uses https://github.com/benedekfazekas/mranderson to isolate dependencies via name munging.
What this output isn't telling me is where it's coming from
do you have a bb.edn with medley in it? or perhaps shadow-cljs? maybe in an alias in deps.edn?
transitively
or project.clj
clojure-lsp just combines anything it can find ;)
Yeah, I just realized I ran -X:deps without any of the aliases. I just don't know how to do it ๐
do you use any aliases with shadow-cljs or clojure-lsp itself?
:aliases '[:foo :bar]' as arguments I think
shadow-cljs, yes
want to bet another beer? ;)
Well, well, well, if it isn't the consequences of my own actions lolcry
The culprit was ๐ฅ Compojure
also a weavejester production!
Which also has @weavejester's name on it ๐
Haha, exactly!
I'll make a PR
Thanks for helping us track this down, it's been a minor annoyance for some time ๐
nice! no problem
๐ป
๐
Apologies for the issue @christian767. I've just released Compojure 1.7.2 that should fix it.
that reminds me, maybe clj-kondo should just warn about this by looking at your deps.edn or project.clj and warn that a library got an org change? not sure if that would really would have detected this issue though
Awesome, thanks @weavejester ! Wasn't a big problem, I'm just glad this long running low key mystery has a conclusion ๐