This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-24
Channels
- # 100-days-of-code (7)
- # announcements (1)
- # bangalore-clj (1)
- # beginners (87)
- # boot (6)
- # cljdoc (16)
- # cljsrn (13)
- # clojure (32)
- # clojure-dev (30)
- # clojure-italy (18)
- # clojure-nl (4)
- # clojure-serbia (1)
- # clojure-uk (48)
- # clojurescript (18)
- # cursive (18)
- # datascript (1)
- # datomic (7)
- # events (9)
- # figwheel-main (28)
- # fulcro (2)
- # hyperfiddle (2)
- # immutant (8)
- # jobs (16)
- # liberator (4)
- # nyc (2)
- # pedestal (15)
- # re-frame (8)
- # reagent (12)
- # reitit (8)
- # remote-jobs (1)
- # ring-swagger (2)
- # robots (1)
- # rum (1)
- # schema (1)
- # shadow-cljs (45)
- # spacemacs (49)
- # sql (13)
- # tools-deps (59)
- # uncomplicate (1)
- # vim (10)
Are there any known issues around depending on an artifact like this: https://repo.maven.apache.org/maven2/ml/dmlc/xgboost-jvm/0.72/
i.e. the only jar for the version has a -javadoc classifier
What are you expecting to happen?
What is your deps.edn?
Hi, sorry for the late response, I raised the issue because while I can build without any issue with leiningen I couldn't make the cljdoc build (which uses tools.deps) work
This is the tools.deps {:deps {org.clojure/clojure #:mvn{:version "1.9.0"}, ml.dmlc/xgboost4j-example #:mvn{:version "0.72"}, ml.dmlc/xgboost-jvm #:mvn{:version "0.72"}, org.clojure/clojurescript #:mvn{:version "1.10.339"}, org.clojure/tools.namespace #:mvn{:version "0.2.11"}, clj-boost/clj-boost #:mvn{:version "0.0.1"}, org.clojure/java.classpath #:mvn{:version "0.2.2"}, org.clojure/data.csv #:mvn{:version "0.1.4"}, ml.dmlc/xgboost4j #:mvn{:version "0.72"}, codox/codox {:exclusions [enlive hiccup org.pegdown/pegdown], :git/url "
It seems impossible to get the XGBoost stuff in this way. While in leiningen I have [ml.dmlc/xgboost4j "0.72" :extension "pom"] and everything's fine
pom extension is not supported - what are you expecting that to do?
I'm not using it, is in cljdoc to build the package, but now I guess there's not much it can be done about it
Sorry, I’m not understanding the problem. It would be very helpful to have a description of the problem, with the things needed to reproduce it, what you expect to happen, and what is actually happening. I feel like the above has half of that but it’s very confusing to me what you’re doing.
I have a dependency, the only way to get it is to use the :extension "pom" flag, I develop, build and release my library with lein, no issues. I wanted to build docs with cljdoc which uses tools.deps and the build fails because of that dependency
“the only way to get it is to use the :extension "pom" flag” - why?
@alexmiller because the dependency doesn’t come with a regular .jar file — I don’t know too much about why you package libraries like this but it seems to be a thing in this case And as far as I understand nobody (using tools.deps) will be able to use @U7P0DPQ1H s library which depends on this artifact
If it doesn’t have a jar, then i don’t get how it affects the classpath.
I guess maybe by having deps
Which I would actually expect to work
If someone could file a jira in TDEPS about this, I will look at it more closely later this week
Yeah would assume that the point of this kind of artifact is usually its deps, I.e. it’s a kind of Uber-module
wont have time to file a ticket in the next few days...
@alexmiller I just opened an issue https://dev.clojure.org/jira/browse/TDEPS-98 hope it's ok
My issue https://dev.clojure.org/jira/browse/TDEPS-50 still reproduces after it has been marked as a duplicate of https://dev.clojure.org/jira/browse/TDEPS-12 which has been marked as fixed. Can someone with access please reopen this for me?
Are you using the latest release?
And what is your deps.edn? There is some new syntax from TDEPS-12 with an example in the comments there.
Specifically you’ll want the lib just once with a coordinate that has :classifier [“” “native”]
{:deps {com.github.jnr/ffi {:mvn/version “1.2.16” :classifier [“” “native”]}}}
Am I nutty or does the example "hello.clj" example from https://clojure.org/guides/deps_and_cli not work until you add :paths ["."] to deps.edn ??
@bherrmann that surprises me for two reasons, one is that it should be "src", the other is that it's a default.
my bad... I'm automating a manual process (converting and excel file) and was thinking more script minded, less software development minded (where a src sub directory is more assumed)
@mkvlr I looked at this and have reopened - you’re right that this is related to TDEPS-12 but needs a bit more work
but I’m not going to get to that this week
@alexmiller thanks a lot! Yes, we can work around by manually specifying it for now so no rush from us. It’s just missing to pick up the classifier when reading the pom if I understand it correctly.
I’m writing some docs on resolving dependency conflicts, is there a tools deps equivalent to lein pedantic?
thanks @alexmiller, while that works and is good to know about it implements lein-ancient it doesn’t find dependency conflicts like pedantic 🙂
oh, sorry. then no :)
there is a totally unsupported subject to removal and alteration verbose mode for tools.deps that is primarily designed to be helpful to me
definitely an area where more could be done
I moved figwheel to Jetty thinking it was a smart move to get https support and to play nicely with larger environment
yeah I spent about 3 hrs early on trying to get Jetty (for local dev) and datomic cloud working. I switched to http-kit and it is working well so far
If I have some.group/artifact {:mvn/version nil} and an :override-deps entry of some.group/artifact {:mvn/version "1.2.3" :exclusions [foo/bar com.quux/blah]} should I expect the :exclusions from the override to be applied to the main dep?
(and what happens if there are :exclusions on both the main dep and the override?)
the override overrides
as in replace the original (including its exclusions)
Cool. So I can rely on specifying :exclusions just once in the overrides -- that's excellent!