Clojurians Log v2

hello @plexus - i hope you're doing well today 🙂 we use bultitude to find namespaces for a specific sub-system. on java 8, our tests for this code work fine. however, on java 11, bultitude seems to have lost access to all the files in the src folder, when running the tests via kaocha. i've done some digging, and i've been able to confirm that the code in the deps.edn profile in the test folder works fine outside of the kaocha runner. i've even altered the kaocha config to force src into the test-paths, with no joy. does any of this trigger a known gotcha that i might be able to look into for you?

We do some funny shenanigans to dynamically add :test-paths to the classpath. Maybe that's getting in your way?

See kaocha.classpath @robert-stuttaford

thanks i'll read!

if that's the culprit then I think we can add a flag to disable that and let people manage their own classpath

i'm pretty sure this is the cause, but i couldn't tell you why specifically - what i see from inside the K run is that only ./test is on the CP and ./src is not. is it perhaps possible there's a java 11 bug in dynapath?

given that it's mucking with classpaths directly

thanks for the quick response btw ^_^

definitely not impossible. I'm not familiar with bultitude but it may also depend on how it figures out the classpath. Does it only look at the current context classloader, or does it follow the chain of classloaders?

pretty sure its just the former

classpath is a bit of a murky concept 🙂 more than one way to determine what "the classpath" is

oh man i feel like i am looking over the edge into a deep dark hole here haha

yeah so that's likely what's happening here. Not all classloaders are modifiable, so to be able to modify the classpath we add a new clojure.lang.DynamicClassLoader to the top of the chain

it's calling clojure.java.classpath/classpathhttps://github.com/TimoFreiberg/bultitude/blob/master/src/bultitude/core.clj#L125

mostly got this working through trial and error, I'm also no export in these JVM specifics. I'm more surprised that it's taken this long before this caused an issue for someone.

my guess is you had to do this to insulate from the different tool contexts - lein/deps/boot?

selfishly, it'd be great if, for our deps case, it just used whatever deps gave it

given that, it sounds like your suggestion of an opt-out flag is the right way to go then

the idea was mainly that you wouldn't have to configure your test paths twice, since we do need to know what your test paths are e.g for --watch or for code coverage

but yeah in practice generally people already have their test paths in their deps.edn or whatever anyway, e.g. for REPL driven dev

thanks for taking the time to talk @plexus 🙂

@robert-stuttaford try {lambdaisland/kaocha {:mvn/version "1.0.632"}}, and add :kaocha.testable/skip-add-classpath? true to the test suite config (so not the top level config but at the same level where you have :test-paths)

ok wow that's awesome i'll try that! thank you sir

it's a one line change but I will admit I did not actually test it. Testing in production like a pro 💪:skin-tone-2:

haha all good, i'll try it out

In java 11, clojure.java.classpath can no longer reflect against the base classloader.

I've pushed a lot of improvements to Chui today, and highly encourage people to try it

Assuming you are using shadow-cljs and :target :browser-test

We'll eventually figure out instructions for figwheel and cljs.main, but to provide the same experience we'll need some extra functionality in figwheel or clojurescript to detect test namespaces and inject them into the build.

with many thanks to @anantpaatra for his great work on the UI design

Feedbacks on the UI are appreciated as well!

Is there something i need to do in order to enable Expound output when running tests? i'm executing the normal -m "kaocha.runner" i see expound alluded to in the docs and could but not how to enable it. i'm too tired to read raw spec errors all day 🙂