Fork me on GitHub
#tools-deps
<
2018-09-24
>
martinklepsch08:09:25

Are there any known issues around depending on an artifact like this: https://repo.maven.apache.org/maven2/ml/dmlc/xgboost-jvm/0.72/

martinklepsch08:09:51

i.e. the only jar for the version has a -javadoc classifier

alexmiller12:09:29

What are you expecting to happen?

alexmiller12:09:58

What is your deps.edn?

alan08:09:43

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

alan08:09:30

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 "", :sha "4b0720941083fda9643d905f0854fabea55b175f", :deps/root "codox/"}}}

alan08:09:00

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

alexmiller12:09:33

pom extension is not supported - what are you expecting that to do?

alan13:09:14

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

alexmiller14:09:12

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.

alan14:09:33

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

alexmiller14:09:48

“the only way to get it is to use the :extension "pom" flag” - why?

martinklepsch14:09:54

@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

alexmiller14:09:49

If it doesn’t have a jar, then i don’t get how it affects the classpath.

alexmiller14:09:42

I guess maybe by having deps

alexmiller14:09:32

Which I would actually expect to work

alexmiller14:09:03

If someone could file a jira in TDEPS about this, I will look at it more closely later this week

martinklepsch14:09:53

Yeah would assume that the point of this kind of artifact is usually its deps, I.e. it’s a kind of Uber-module

martinklepsch14:09:59

wont have time to file a ticket in the next few days...

mkvlr10:09:29

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?

alexmiller12:09:20

Are you using the latest release?

alexmiller12:09:28

And what is your deps.edn? There is some new syntax from TDEPS-12 with an example in the comments there.

alexmiller12:09:20

Specifically you’ll want the lib just once with a coordinate that has :classifier [“” “native”]

alexmiller12:09:23

{:deps {com.github.jnr/ffi {:mvn/version “1.2.16” :classifier [“” “native”]}}}

bherrmann12:09:04

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 ??

dominicm12:09:56

@bherrmann that surprises me for two reasons, one is that it should be "src", the other is that it's a default.

dominicm12:09:04

Where did you put hello.clj?

bherrmann12:09:00

ok, yea. hello.clj just needs to be under "src"

bherrmann12:09:22

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)

alexmiller14:09:09

@mkvlr I looked at this and have reopened - you’re right that this is related to TDEPS-12 but needs a bit more work

alexmiller14:09:17

but I’m not going to get to that this week

mkvlr14:09:06

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

bhauman14:09:02

I’m writing some docs on resolving dependency conflicts, is there a tools deps equivalent to lein pedantic?

bhauman14:09:35

thanks @alexmiller, while that works and is good to know about it implements lein-ancient it doesn’t find dependency conflicts like pedantic 🙂

alexmiller14:09:49

oh, sorry. then no :)

bhauman14:09:24

-Stree helps of course

alexmiller14:09:42

there is a totally unsupported subject to removal and alteration verbose mode for tools.deps that is primarily designed to be helpful to me

bhauman14:09:15

oh I’ll put that in the docs then 😉

alexmiller14:09:38

definitely an area where more could be done

bhauman14:09:26

I moved figwheel to Jetty thinking it was a smart move to get https support and to play nicely with larger environment

bhauman14:09:42

but dang its prone to tricky conflicts

bhauman14:09:13

the way the package is divided up

bhauman14:09:29

when I say tricky I mean tricky for newcomers

bhauman14:09:23

the conflict between ring and datomic cloud is the main problem

☝️ 4
lilactown16:09:37

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

bhauman21:09:49

@U4YGF4NGM I’ve got docs on this now

4
bhauman21:09:46

published it this weekend

bhauman21:09:52

sorry about that

lilactown21:09:03

awesome! ty!

seancorfield21:09:13

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?

seancorfield21:09:32

(and what happens if there are :exclusions on both the main dep and the override?)

alexmiller21:09:41

the override overrides

alexmiller21:09:26

as in replace the original (including its exclusions)

seancorfield21:09:47

Cool. So I can rely on specifying :exclusions just once in the overrides -- that's excellent!