Fork me on GitHub
#yada
<
2020-04-02
>
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.

mccraigmccraig06:04:42

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

mccraigmccraig06:04:21

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

mccraigmccraig06:04:32

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

dominicm06:04:16

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 🙂

mccraigmccraig06:04:30

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

dominicm06:04:52

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

dominicm06:04:40

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 ?

mccraigmccraig06:04:45

ah, yeah, probably true

dominicm06:04:06

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

 :aliases
 {: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"}
                      }
         }}
 }

dominicm06:04:01

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

dominicm06:04:39

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: