This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-02
Channels
- # announcements (15)
- # aws-lambda (1)
- # babashka (2)
- # beginners (25)
- # calva (2)
- # cider (6)
- # cljfx (6)
- # clojure (24)
- # clojure-boston (1)
- # clojure-dev (2)
- # clojure-europe (31)
- # clojure-uk (2)
- # clojurescript (48)
- # community-development (4)
- # conjure (1)
- # datahike (4)
- # datascript (10)
- # datomic (1)
- # deps-new (1)
- # fulcro (10)
- # juxt (1)
- # malli (7)
- # missionary (1)
- # nrepl (2)
- # off-topic (2)
- # other-languages (5)
- # polylith (4)
- # random (1)
- # react (2)
- # shadow-cljs (9)
- # tools-deps (21)
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
You need to update your CLI
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?
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
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.
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!).
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?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
Yes, OSX. In this case, what is the solution?
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
It is that
@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...
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"}
That shaded library is the only one I've run across that causes this problem.
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"}
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.
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:
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...
Great catch!