Clojurians Log v2

Oh, thanks for fixing this. Had been affecting me too, took me ages to work out what was going on since the dependencies were several levels deep in the tree, and of course I couldn't reproduce it in just one module. Really appreciate how quickly you've been able to roll out a fix

No

Thanks, I'll try that - a few people have been reporting similar issues that I haven't managed to reproduce.

perhaps because cursive statically analysis this?

Yes, Cursive tries to work out the transitive closure of namespace deps, so that it can send a namespace and any out-of-date deps in dependency order. But statically figuring out whether there really are loops (especially with CLJC madness) can be tricky.

yeah this var-info-gen namespace has a in-ns thing in it which may confuse cursive's analysis

it's required from var-info, so you have var-info-gen required by var-info but var-info-gen does an in-ns of var-info

it's kind of the same trick that clojure.core does with deftype etc

Cursive used to handle that ok, perhaps something has either broken or changed in ways I didn't anticipate. I'll check that out anyway, thanks for the pointer.

I can't reproduce with that ns either, I'm not sure what's going on.

Clojure version 1.12.0, don’t know what else to help you

@roklenarcic Does rebuilding indexes help (File | Invalidate Caches)?

So yeah initially this happened in a development namespace, now it’s happening in more important namespaces

Could you check the module that it's happening in (File | Project Structure | Modules | <your module> | Dependencies) and see if there are two versions of Kondo there?

Hm there’s just one, but that one is 2023.07.13 version

Ok, I'll try to reproduce using that version.

I mean I tried to load both here:

and they both have the same error when I try to load them like this from the opened source

Ah I see what’s a problem, they 2023 version doesn’t work. The project has a module with 2023 and a module with 2025 version, so they both show up in the jar list and if I try to open var_info_gen I can choose which source from which lib to open, and both throw an error when I try to load them. Then if I remove 2023 completely, so only 2025 version exists in the project (which has several modules), then it works.

Ok, now I started a repl in module that includes 2025 version only and it still throws an error

Yeah this is weird. So basically the I have base-module, it has kondo 2025, then I have module 1 that depends on base module and module 2 that depends on base module, that also has dependency on kondo 2023. Starting REPL for ANY of these modules, opening the var_info_gen.clj from 2025 version and trying to load it into active repl will produce dependency cycle error. Then I update kondo 2023 dependency in module 2 deps to 2025. This is where it gets weird. Besides fixing module 2, that also fixes module 1 and base module, now REPLs for those modules can load the var_info_get.clj file just fine.

Loading

That sounds plausible. This is a result of this change: https://github.com/cursive-ide/cursive/issues/3023. As a result of widening the allowable scope, it now frequently pulls in multiple versions of the same lib, which didn't happen previously. I'll see if I can fix this, otherwise I'll roll back this change and find another way to support build REPLs.

There's a fix for this out in 2025.1.1-eap1.