This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-12
Channels
- # beginners (58)
- # boot (4)
- # calva (1)
- # cider (13)
- # cljdoc (1)
- # cljs-dev (7)
- # cljsrn (14)
- # clojure (93)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-germany (1)
- # clojure-italy (6)
- # clojure-losangeles (3)
- # clojure-nl (8)
- # clojure-spec (6)
- # clojure-uk (77)
- # clojurescript (3)
- # cursive (5)
- # data-science (6)
- # datomic (52)
- # emacs (1)
- # figwheel-main (2)
- # fulcro (6)
- # graphql (7)
- # jobs (9)
- # leiningen (1)
- # luminus (15)
- # mount (14)
- # off-topic (94)
- # pedestal (1)
- # re-frame (7)
- # reagent (10)
- # shadow-cljs (75)
- # spacemacs (4)
- # test-check (15)
- # tools-deps (23)
- # unrepl (1)
Re: yesterday’s discussion of depstar, this is apparently floating around https://github.com/luchiniatwork/cambada
Yeah, that is a lot more comprehensive but has a lot of knobs and dials -- and has its own set of surprises, I gather, from people who've used it.
@doglooksgood :exclusions
work fine in deps.edn
Do you have a specific case where you think it doesn't work?
@doglooksgood there isn't a top level exclusions though, which is something people try though, only a per-dependency exclusions.
@seancorfield When using leiningen, usually I found there're some conflicts in my dependencies, but with clojure -Stree
, I don't get any information like this.
@doglooksgood I think tools.deps operates on a different principle to maven/lein, so conflicts are less of an issue. tools.deps always picks the newest version, as opposed to maven which picks the first one it finds.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/tianshu/.m2/repository/org/slf4j/slf4j-nop/1.6.2/slf4j-nop-1.6.2.jar!/org/slf4j
/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/tianshu/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2
.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See for an explanation.
SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]
I want to remove one of the binding, but don't know where introduce the multiple bindings.with lein I got some information like this:
Possibly confusing dependencies found:
[org.quartz-scheduler/quartz "2.3.0"] -> [org.slf4j/slf4j-api "1.7.7"]
overrides
[conman "0.8.1"] -> [hikari-cp "2.4.0"] -> [com.zaxxer/HikariCP "3.1.0"] -> [org.slf4j/slf4j-api "1.7.25"]
and
[org.quartz-scheduler/quartz "2.3.0"] -> [com.zaxxer/HikariCP-java6 "2.3.13"] -> [org.slf4j/slf4j-api "1.7.10"]
and
[ch.qos.logback/logback-classic "1.2.3"] -> [org.slf4j/slf4j-api "1.7.25"]
Consider using these exclusions:
[conman "0.8.1" :exclusions [org.slf4j/slf4j-api]]
[org.quartz-scheduler/quartz "2.3.0" :exclusions [org.slf4j/slf4j-api]]
[ch.qos.logback/logback-classic "1.2.3" :exclusions [org.slf4j/slf4j-api]]
then I know I can remove the binding by add exclusions on the org.quartz-scheduler/quartz
dependency.
@doglooksgood this is different to conflicting dependencies. clj -Stree
gives you the information you need to fix this, you need to find which dependency is bringing in the logback you don't want, either nop of logback-classic.
I don’t think -Stree actually does provide info to do that - it just lists what is used, not what isn’t
This is an area that needs some more work
If you don’t like the one you’re getting, you can try excluding that one and see which one you get instead
@alexmiller that's what I meant. It will show where logback-nop comes from.
@alexmiller Any thoughts on adding some sort of "pedantic" check to tools.deps
?
in terms of reporting or also failing on pedanticness?
Are there any plans to allow whitespace in strings?
I was reading the edn spec and it says commas are not treated as whitespace within strings, but I must use them for arbitrary code using -e
for example
would like to allow, in practice it’s painful due to the interaction with the shell
I see. Editor word-wise commands etc get confused so it's painful to edit