Fork me on GitHub
#tools-deps
<
2021-10-02
>
yuhan16:10:31

Slightly confused about clj -T / :tools/usage key in deps.edn - is this deprecated? I get the error

> clj -Ttools list
-T is no longer supported, use -A with repl, -M for main, or -X for exec

Alex Miller (Clojure team)16:10:34

You need to update your CLI

yuhan16:10:59

oh! so it's a relatively new feature, got it

yuhan16:10:49

Am I right in understanding that clj -T install lib :as name is a sort of UX improvement over adding a :name alias in my ~/.clojure/.deps.edn with some map of :deps and :main-opts as copied from the library's readme?

yuhan17:10:26

Seems like it! I just read the excellent docs over at https://github.com/seancorfield/dot-clojure, hopefully this catches on as an alternative to lein plugins :) Although I'm still unsure why git deps are being recommended over the more familiar Maven coordinates, both seem to work

seancorfield20:10:57

Git deps let you depend on libraries that aren't published, or on specific versions that haven't been published yet, such as PRs. For "tools" in particular, there's no point in publishing them (to Clojars) because they are not "libraries" and people aren't building applications that depend on them.

👌 1
seancorfield20:10:34

I like git deps a lot. As I noted in another recent thread about this topic, we don't happen to have any git deps in our QA/production artifacts (JARs) but that really is just "coincidence" since we rely on git deps a lot in our dev/test infrastructure (and, in particular, on a lot of dev/test tooling that is not published to Clojars!).

athomasoriginal19:10:09

I’m in the process of moving from depstar to tools.build. Everything seems to be configured correctly, but when I run b/uber I get the following exception:

Cannot write META-INF/license/LICENSE.tomcat-native.txt from io.grpc/grpc-netty-shaded as parent dir is a file from another lib. One of them must be excluded.
Looking around it seems like this scenario should be covered by the default conflict handlers?

dpsutton19:10:59

Are you on OS X?

👍 1
dpsutton19:10:30

This might be the issue where there is already a file named license so it cannot make a directory named LICENSE on a case insensitive file system

athomasoriginal19:10:58

Yes, OSX. In this case, what is the solution?

dpsutton19:10:09

add an exclusion on "LICENSE". Usually there is a file called LICENSE that exists so there is no way to make a folder called "license" to put the LICENSE.tomcat-native.txt file

👍 1
seancorfield20:10:31

@tkjone We ran into that at work and added an exclusion on grpc-netty-shaded and used a different implementation instead (that produced a noticeably smaller uberjar!)... just a sec and I'll pull that up...

seancorfield20:10:16

com.google.cloud/google-cloud-vision {:mvn/version "1.103.7"
                                        :exclusions [io.grpc/grpc-netty-shaded]}
  io.grpc/grpc-okhttp {:mvn/version "1.41.0"}

seancorfield20:10:59

That shaded library is the only one I've run across that causes this problem.

athomasoriginal22:10:01

Outstanding! Did the same thing and it seems to have worked perfectly. For future readers, in my case the solution was:

com.google.firebase/firebase-admin              {:mvn/version "8.1.0"
                                                   :exclusions  [io.grpc/grpc-netty-shaded]}
  io.grpc/grpc-okhttp                             {:mvn/version "1.41.0"}

seancorfield22:10:05

My reading suggests that there are three possible implementations that the Google libraries can use, with grpc-netty-shaded just being the default. There's an unshaded version but that can cause conflicts if you also depend on netty-io directly (as we do at work), and then there's the okhttp one which is at least smaller, and seems less problematic from a conflict p.o.v.

athomasoriginal22:10:45

I’m not familiar enough with Java land to even have realized that this is a thing I could look at doing. Glad to see someone else ran into this. It seems off in general because from the look of it, it was just a license file which couldn’t be created. :thinking_face:

seancorfield22:10:19

I wouldn't have even thought to look for alternatives if I hadn't run over the case-sensitivity conflict (of a LICENSE file in most libraries but a license directory in this one). Since okhttp is substantially smaller, I'm happy with the change. I can't even remember where I found the documentation saying you could swap out the implementations...