Clojurians Log v2

Neat idea! Looking at our plugin kaocha-cljs, it doesn't look like we do anything special dependencywise. (And I can confirm it works fine on projects using different versions—I've used kaocha-cljs on projects using newer versions lately.) What specific dependency conflicts are you seeing?

Well, the ones above 🙂 I can do a :deps tree when I have an available timeslot.

Maybe the project I was testing it on had a particularly old version of Kaocha.

Thanks!

The projects I’m working with have generally have :pedantic? :abort in their project.clj, so any conflict, even benign, becomes obvious immediately.

Ahh, I tried pendantic? :abort and it did turn up a kaocha and kaocha-cljs conflict (expound). I'm not sure it's actually a problem but it might be worth harmonizing dependency versions across kaocha and its plugins. Maybe you're already familiar, but it looks like :managed-deps is the primary tool lein offers to fix these kinds of problems: https://github.com/technomancy/leiningen/blob/830d19d5b9f9e2b0e3411428d83422791ca2f814/doc/MANAGED_DEPS.md#managed-dependencies

@actuallyalys_slack that seems related, but not an exact solution to what I’m talking about. With managed dependencies, there won’t be a conflict, so that part is taken care of, but I also have no guarantee that the runtime Kaocha version harmonizes with my plugin. Thanks a lot for the heads up, though, didn’t know about that!

@reefersleep You're welcome! We can't make compatibility guarantees, but is there something we could do, maybe in our test matrix, to give you more confidence as a plugin author? Are there particular conflicts you're afraid of?

@actuallyalys_slack nothing in particular - I haven’t kept up to date with the Kaocha changelog 🙂 And don’t know the roadpath. @javahippie suggested recording the Kaocha version(s) that I’ve tested the plugin with, use Kaocha as a :provided dependency, and look up the dependency in the classpath on intialization, then give the user a warning if it’s not in the list of tested versions. Seems like a decent tradeoff. @ordnungswidrig suggested using MrAnderson to pull in the “correct” Kaocha version under a different name in my plugin, essentially having it twice on the classpath. A good alternative to know of, but too bloaty for my use case, I think.

@reefersleep Yeah, I'd discourage using MrAnderson because it seems way too heavyweight unless you actually know of incompatibilities. I generally wouldn't expect plugins to be version dependent, unless they rely on new functionality. Warning about potentially incompatible versions makes more sense, although you might want to give users the option of silencing it or providing additional tested versions--I'd expect most versions to work and the warning could become noise.

@reefersleep As for the roadmap, we perhaps should have one, but I'm not aware of any plans to make changes that would break backwards compatability. (If we made such a change, we'd definitely note it in the changelog.)

Good point on the silencing option.

I never suspected anything to break in the face of a conflict, I figure Kaocha is pretty stable already (and has got some stable maintainers 😉 that take care of such things), but why not consider the possibility.

@actuallyalys_slack I added a suppressing option which can be activated through tests.edn. Do you know how I would activate it through the command line? It’s just a boolean.

I’ve described the tests.edn usage here: https://github.com/Reefersleep/gitcha