Fork me on GitHub
Danny Almeida00:04:18

@dominicm @mccraigmccraig This was part of my learning about yada and how to use it to serve resources. just a few basic resources of different types i.e. As part of that excercise, i wanted to add a clojurescript frontend and added clojurescript and shadow-cljs as a dependency. That's when it started giving the error. If I commented out shadow-cljs, the error went away. I did use lein deps :tree and tools.deps clj -Stree, but I couldn't figure out from the output, a way to resolve this. But adding clj-time as a dependency stopped the error.


sounds like you were in jar-hell @dionysius.almeida - the way out usually involves adding explicit deps and excluding some implicit deps


with lein i find it helpful to use :pedantic? :abort , which forces you to consider every transitive dep conflict explicitly, or it errors


i don't know if there's an equivalent deps.edn construct


Deps doesn't have this problem so much. It doesn't have that option.

Danny Almeida06:04:19

@mccraigmccraig Yeah..learn't something new i guess. Also, including :pedantic? :abort caused each run to suggest more exclusions ..and it kept going on, so I gave up on it. Since I consider myself a beginner to clojure, this is not something I would want to spend time looking into. For now, if I encounter any such errors, I understand that adding an explicit dependency this the way to go. Cheers 🙂


i seem to recall reading that deps had a saner conflict resolution by default


I think what's more likely is that clj-time was coming in by accident, and being used.


Then in an updated version of whatever brought in clj-time, no longer brought it in.

Danny Almeida06:04:15

I read somewhere that deps resorts to newest version while lein resolves to older version..not sure if this is true

Danny Almeida06:04:03

@dominicm not sure what you mean ? It's being used by yada/cookies.clj ..isn't that how it's being included ?


ah, yeah, probably true


@dionysius.almeida in that case I'd love to see your deps edn, and I should double check that yada behaves here

Danny Almeida06:04:55

Here's my deps.edn, nothing special. This is after adding clj-time

{:paths ["src/clj" "src/cljs" "resources"]
 :deps {org.clojure/clojure        {:mvn/version "1.10.0"}
        yada                       {:mvn/version "1.4.0-alpha1"}
        integrant                  {:mvn/version "0.8.0"}
        prismatic/schema           {:mvn/version "1.1.12"}
        clj-http                   {:mvn/version "3.10.0"}
        com.cognitect/transit-clj  {:mvn/version "1.0.324"}
        org.clojure/test.check     {:mvn/version "1.0.0"}
        com.taoensso/timbre        {:mvn/version "4.10.0"}
        clj-time                   {:mvn/version "0.15.2"}
        com.fzakaria/slf4j-timbre  {:mvn/version "0.3.19"} ;; To log slf4j to timbre

 {:dev  {:extra-paths ["dev"]
         :extra-deps {org.clojure/clojurescript    {:mvn/version "1.10.520"}
                      thheller/shadow-cljs         {:mvn/version "2.8.92"}
                      binaryage/devtools           {:mvn/version "0.9.10"}
                      org.clojure/tools.namespace  {:mvn/version "1.0.0"}
                      keechma                      {:mvn/version "0.3.5"}


It would indeed appear that yada does not depend on clj time!


That's great, thanks. I'll have a little poke at the before after tree, but this seems to be a yada bug.

Danny Almeida06:04:10

@dominicm thanks 👍:skin-tone-3: