This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (13)
- # babashka (59)
- # beginners (58)
- # bitcoin (3)
- # calva (7)
- # cider (2)
- # cljsrn (4)
- # clojure (41)
- # clojure-dev (18)
- # clojure-germany (1)
- # clojurescript (14)
- # conjure (7)
- # cursive (5)
- # datahike (1)
- # graalvm (44)
- # jobs-discuss (3)
- # kaocha (19)
- # lsp (109)
- # luminus (3)
- # off-topic (8)
- # pathom (32)
- # re-frame (4)
- # reveal (3)
- # shadow-cljs (16)
- # spacemacs (5)
- # sql (18)
- # vim (13)
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?
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.)
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.