Fork me on GitHub
#tools-deps
<
2019-07-29
>
borkdude10:07:50

@dominicm good to know that doesn't work yet - if it did, that would be a reason for me to jump from boot to tools.deps in our local codebase, since we have locally shared deps now that we must deploy somewhere, which feels a bit icky

Alex Miller (Clojure team)14:07:07

as TDEPS-132 indicates, I consider this out of scope for now, no plans to work on that

borkdude17:07:28

is there something in tools.deps which combines R and C? so I want all test deps but also the test dir to be on the classpath

borkdude17:07:59

so clojure -Rtest -Ctest -Spath

borkdude18:07:44

but won't that also execute a main?

Alex Miller (Clojure team)18:07:32

yes, if there is one in the test alias. you didn't mention that

Alex Miller (Clojure team)18:07:18

if that's the case, then I'd say no, use -R and -C

borkdude18:07:00

well, I only know after looking, so it's not something I would use by default that way

borkdude18:07:44

and people might add one later, so if I do that in a script, the script might break

borkdude18:07:54

so -R and -C is fine

kenny23:07:17

Every time I run clj in some of my projects, I get all of this outputted:

Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-netty-shaded/maven-metadata.xml from 
Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Downloading: io/grpc/grpc-core/maven-metadata.xml from 
Downloading: io/grpc/grpc-api/maven-metadata.xml from 
Is this necessary?

seancorfield23:07:46

@kenny That indicates you are either depending on SNAPSHOT releases or RELEASE/LATEST rather than specific non-snapshot versions.

kenny23:07:24

That would surprise me. Would that show up in -Stree?

seancorfield23:07:39

Since snapshots and both RELEASE/LATEST can refer to different versions over time, the dependency checker must fetch metadata to check which version is current.

seancorfield23:07:51

Yeah, I would expect it to show up in -Stree

kenny23:07:18

Nothing shows up using any of those identifiers.

seancorfield23:07:42

Well, something is trying to pull in io.grpc/grpc-core and/or io.grpc/grpc-api...

kenny23:07:05

Correct but -Stree shows the version locked.

seancorfield23:07:34

-Stree shows what version it is resolved to -- not necessarily how it was declared.

seancorfield23:07:11

So using the output of -Stree you can figure out what path through the dependencies was taken -- and then look in your deps.edn to see how you're pulling those top-level things in...

kenny23:07:35

Well it's from this dep: com.google.cloud/google-cloud-monitoring {:mvn/version "1.78.0"}

kenny23:07:12

I think it'd be weird for that lib to use one of those identifiers.

kenny23:07:16

Ah, was just ctrl+f'ing. That's a weird way to do it.

kenny23:07:38

So because they didn't specify a version, tools-deps tries to find the latest one each time?

kenny23:07:12

Bleh. Why would they do that?

seancorfield23:07:33

Because they're Google? You can probably fix that by putting those dependencies explicitly in your project with appropriate versions...

4
seancorfield23:07:07

So maybe tools.deps doesn't follow that path? @alexmiller might be able to speak to that.

seancorfield23:07:30

But at least that gives the specific versions you'd be expected to use (with GCM 1.78.0)

kenny23:07:36

Is a parent supposed to be included in the dep tree or only used to resolve artifacts in the child?

seancorfield23:07:55

(look at the <properties> section of that parent pom I linked to)

seancorfield23:07:06

That question is beyond my Maven knowledge, sorry.

kenny23:07:15

So weird. Everything works as expected in the REPL.

seancorfield23:07:41

in the clj repl?

seancorfield23:07:03

Right, because it resolves all the versions.

seancorfield23:07:05

I'm just suggesting you can suppress those metadata fetches by explicitly declaring dependencies in deps.edn on the relevant versions of io.grpc/grpc-core, io.grpc/grpc-api, etc.

seancorfield23:07:51

I have a bunch of dev-only tooling where I use RELEASE as the version and every day clj will show messages about fetching metadata -- to check the most recent version.

seancorfield23:07:32

In your -Stree output, what version of those io.grpc libs does it show that it resolves to?

kenny23:07:24

Adding io.grpc/grpc-core {:mvn/version "1.21.0"} fixes this.

seancorfield23:07:47

Yup. That's what I'd expect.