Fork me on GitHub
#tools-deps
<
2019-08-08
>
Alex Miller (Clojure team)02:08:47

Just fyi on kind of a tangent, core.rrb-vector is a Clojure contrib and the only build officially supported for those for build and deploy is the pom.xml - that has to be the primary

Alex Miller (Clojure team)02:08:08

it's ok for it to also have a deps.edn

Alex Miller (Clojure team)02:08:25

and the tool for variant classpaths is aliases

andy.fingerhut02:08:30

But the pom.xml is a no-op for ClojureScript, isn't it?

Alex Miller (Clojure team)02:08:03

we have other contrib libs that build a single jar usable from either

Alex Miller (Clojure team)02:08:11

data.xml, tools.reader, etc

andy.fingerhut02:08:26

I guess the pom.xml controls what ClojureScript source files are bundled up in there.

seancorfield02:08:56

(tools.cli is pure .cljc so it may not be a good example for you)

Alex Miller (Clojure team)02:08:28

the trickiest part of clj/cljs contribs is testing and probably data.xml is the most advanced example out there

andy.fingerhut02:08:04

I will take a look at data.xml more carefully. I know pretty much all contribs do automated build and at least a subset of their tests automated with results on http://build.clojure.org. Do you know if any of them build and test ClojureScript code?

andy.fingerhut02:08:05

Ah, I see in the console log for data.xml that it does run some cljs tests using nashorn JavaScript runtime.

seancorfield02:08:23

I should have a look at that too since the Maven build for tools.cli only does clj testing, and I do cljs testing manually via deps.edn...

Alex Miller (Clojure team)02:08:47

those are the main ones I can think of that do cljs testing

Alex Miller (Clojure team)02:08:05

"building" is really just including the cljs in the jar so not really a big deal, a bunch of contribs do that

Alex Miller (Clojure team)02:08:36

in a lib like core.async there is a manual cljs test process that we run by hand, but it's not part of ci

andy.fingerhut02:08:08

So that is a great lead-in to what the pom.xml should ideally do (i.e. automate ClojureScript as well as Clojure tests), and I can look into that. Definitely nicer with a working example to start from.

andy.fingerhut02:08:49

As far as deps.edn file goes, would it be bad to have one, if its contents conflict with what pom.xml says?

Alex Miller (Clojure team)02:08:58

many of the contribs also have project.clj files

andy.fingerhut02:08:55

deps.edn in a Maven-deployed JAR file should either (a) not be in the JAR, or (b) ignored by tools.deps, Maven, etc. even if one is in there?

Alex Miller (Clojure team)02:08:48

I don't think it would be in the jar file

Alex Miller (Clojure team)02:08:54

and it would be ignored by Maven

Alex Miller (Clojure team)02:08:22

there are plenty of examples to check -a bunch have deps.edn files

Alex Miller (Clojure team)02:08:41

tools.deps won't ignore it but presumably that's the point

Alex Miller (Clojure team)02:08:55

if this gets too into the weeds on contrib, I would move it to #clojure-dev

andy.fingerhut02:08:58

Understood. If I haven't exhausted you with questions yet, is it short to explain what happens when tools.deps follows a dependency to a git repo, and that git repo has both pom.xml and deps.edn files?

andy.fingerhut02:08:37

If that is involved, no worries, I can wait.

andy.fingerhut02:08:49

(or experiment)

Alex Miller (Clojure team)02:08:24

that's why I said it matters to tools.dep

andy.fingerhut02:08:23

thx. Keeping some notes separate from here for future reference.

seancorfield03:08:32

@andy.fingerhut When building JARs, you're mostly just going to get src and the META-INF stuff (which includes a pom.xml file) but nothing else from the repo (so no deps.edn file).

seancorfield03:08:06

When you depend on a JAR, the transitive dependencies are figured out from that embedded pom.xml file (as I found out recently with depstar!).

seancorfield03:08:31

When you depend on a git or local repo, tools.deps will use deps.edn if present else pom.xml. If neither are present, you can tell tools.deps to "assume" deps.edn (and it treats the absence as an empty {}).

seancorfield03:08:04

:deps/manifest :deps

hkupty15:08:46

Hey, when using tools.deps on a git dependency (which is a tools.deps project itself as well), can I load an alias of this dependency? The use-case is: I want to dynamically load a project using tools.deps+dynpath (up to this point I got it running), access its test/ folder and run the tests. No specific project yet, just trying some ideas.

Alex Miller (Clojure team)15:08:54

but something under consideration

hkupty15:08:01

I think that could be solved by adding paths and deps with resolve-deps and make-classpath then.

hkupty15:08:10

If I got it right, then calling (make-classpath {...} ["test"] nil) could allow that, right?

Alex Miller (Clojure team)15:08:53

need more words to understand what you mean

Alex Miller (Clojure team)15:08:06

what is "that" and "it"?

hkupty16:08:04

My intent of being able to run the tests from a dependency I pull dynamically as explained in the use case above.

Alex Miller (Clojure team)16:08:20

then, yes that should work

Alex Miller (Clojure team)16:08:35

you probably want to also include the source paths though I would assume

hkupty16:08:57

Good. Thanks for the help.

jrwdunham18:08:02

Can someone here help me to understand how I can rebuild/re-install a local dependency without quitting and restarting Spacemacs/Cider? I was originally declaring a Git dependency and then I changed my deps.edn file so that the dependency was to a local path. That is, my deps.edn started out as {:deps github-myorg/mylib {:git/url "" :sha "6c9cbfa1b1721b3d7789e6ff65a3c01065fd6c54"}} and changed to {:deps mylib {:local/root "/path/to/root/of/mylib"}}.

Alex Miller (Clojure team)18:08:38

you'll have to restart your repl to pick that up

jrwdunham19:08:28

thanks @alexmiller. I was thinking that would be necessary, but was hoping not

kenny23:08:14

I have a project that depends on a library A via :local/root. Library A depends on com.google.cloud/google-cloud-monitoring. google-cloud-monitoring depends on commons-logging. In library A, I have :exclusions [commons-logging] set on com.google.cloud/google-cloud-monitoring. When I run clj -Stree in my top level project, I still get commons-logging/commons-logging in the tree. If I run clj -Stree in library A, I also get commons-logging. Any idea what is going on here?

kenny23:08:42

Global exclusions would solve this btw ^

seancorfield23:08:13

@kenny commons-logging is used by a lot of things -- perhaps something else is bringing it in?

kenny23:08:31

Perhaps. But it is shown under com.google.cloud/google-cloud-monitoring

Alex Miller (Clojure team)23:08:31

where do you see it in the tree?

Alex Miller (Clojure team)23:08:13

did you try :exclusions [commons-logging/commons-logging] ?

kenny23:08:18

Well, several layers deep in there

kenny23:08:27

No, I can though. I thought they'd be the same.

Alex Miller (Clojure team)23:08:36

I wonder if there's a non-canonicalized matching canonicalized somewhere

kenny23:08:45

com.google.cloud/google-cloud-monitoring 1.78.0
  javax.annotation/javax.annotation-api 1.3.2
  com.google.cloud/google-cloud-core-grpc 1.78.0
    com.google.auth/google-auth-library-credentials 0.16.1
    io.grpc/grpc-protobuf 1.21.0
      io.grpc/grpc-protobuf-lite 1.21.0
    com.google.api/gax-grpc 1.45.0
      io.grpc/grpc-alts 1.21.0
        org.apache.commons/commons-lang3 3.5
        io.grpc/grpc-grpclb 1.21.0
    com.google.protobuf/protobuf-java 3.7.1
  io.grpc/grpc-stub 1.21.0
  com.google.api.grpc/proto-google-cloud-monitoring-v3 1.60.0
  com.google.cloud/google-cloud-core 1.78.0
    com.google.api.grpc/proto-google-iam-v1 0.12.0
    com.google.protobuf/protobuf-java-util 3.7.1
    com.google.api/api-common 1.8.1
    com.google.http-client/google-http-client 1.30.1
      com.google.j2objc/j2objc-annotations 1.3
      io.opencensus/opencensus-contrib-http-util 0.21.0
      org.apache.httpcomponents/httpclient 4.5.8
        org.apache.httpcomponents/httpcore 4.4.11
        commons-logging/commons-logging 1.2

Alex Miller (Clojure team)23:08:09

if you can, I'd try changing the exclusion

4
kenny23:08:13

Commenting google-cloud-monitoring shows another dep bringing it in. I guess I can follow the trail.

kenny23:08:41

commons-logging/commons-logging does it

kenny23:08:16

Gosh, I wonder how many other places have an exclusion that isn't qualified and it should be :thinking_face:

kenny23:08:24

Wait, now commons-logging is showing up in another location in the tree.

Alex Miller (Clojure team)23:08:11

yeah, the code doesn't canonicalize the exclusions

kenny23:08:45

Changing the :exclusions in a :local/root dep does not invalidate the clj cache.

Alex Miller (Clojure team)23:08:50

Yeah, that’s a known issue

Alex Miller (Clojure team)23:08:30

I have a plan to fix it but it’s a pain

kenny23:08:12

Gotcha, ok. Out of curiosity, would it be possible to resolve deps in parallel?

Alex Miller (Clojure team)23:08:56

Yes, have thought about it some

Alex Miller (Clojure team)23:08:06

Generally you have most stuff in local repo already so I don’t find it critical