Hmmm… get a lot of dependency conflicts in projects that include kaocha, which they naturally will. Do you know of a good way to fix this? I don’t know if :provided is a solid solution, won’t I either require the plugin user to use my version of kaocha, or risk subtle incongruencies if somebody uses another version than I assume? (I know the gist of :provided, but not the nitty gritty)

e.g., this is the dependency after fixing all conflicts in a random project. I don’t want to force this on users if I can avoid it.

[gitcha "0.1.0-SNAPSHOT"
 :exclusions [lambdaisland/kaocha
 org.clojure/spec.alpha 
 expound
 org.clojure/tools.cli
 aero
 lambdaisland/tools.namespace
 orchestra
 org.tcrawley/dynapath]]

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

@U01FJUDL57C 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!

@U0AQ3HP9U 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?

@U01FJUDL57C nothing in particular - I haven’t kept up to date with the Kaocha changelog 🙂 And don’t know the roadpath. @U0N9SJHCH 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. @U054UD60U 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.

@U0AQ3HP9U 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.

@U0AQ3HP9U 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.

@U01FJUDL57C 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