Fork me on GitHub

@hlolli, for now, you have to have (set! *warn-on-reflection* true) in each source file. I think it's a good habit to get into.

👍 4

how would a subdirectory fit with git/url, thinking of

Alex Miller (Clojure team)02:05:30

you can specify :deps/root as a subdir in which to find deps.edn/pom.xml in the context of a git lib

Alex Miller (Clojure team)02:05:17

doesn't look like that project needs that though? there's a deps example in the readme


Is there a way to add clojure$slim (slim classifier) as a dependency and exclude the clojure dependency that comes with tools.deps ? Adding clojure$slim to deps.edn results in both clojure and clojure$slim to be on the classpath. Looks like a consequence of the recent classifier change ?


Ah, because it comes in from the "system" deps.edn, that's interesting.


I guess the original :classifier design was better for this case.

Alex Miller (Clojure team)11:05:06

no not possible right now. Classifier deps really are treated as separate deps and because Clojure is included by default, there is no way to remove it

Alex Miller (Clojure team)11:05:26

Hadn’t ever thought of this re slim (almost no one uses it)


is there a way to determine a proper “groupId” from a deps.edn? not really right?

Alex Miller (Clojure team)15:05:11

You mean for deps or for the project itself?


for the project itself


not super important, I’m just writing a utility to add a dep to a project via command line. ran into where: - plum add org.clojure/clojure "1.10.0" appends org.clojure/clojure {:mvn/version "1.10.0"} - plum add "some-long-sha" right now adds as

clojure/clojure {:git/url "" :sha "some-long-sha"}


the pragmatic thing to do would be to check for a pom.xml in the repo, I suppose. or just not worry about it

Alex Miller (Clojure team)15:05:35

well using clojure as a git dep like that won't work (as it's half java and must be compiled into an artifact)


ah, fair point


I think the problem exists still as: I want to use the latest version on git of a library that I previously was consuming through maven. with my naive approach, a user might end up with two different identifiers in their deps.edn for the same lib


which, btw, what would the behavior be in that case? last one wins?

Alex Miller (Clojure team)15:05:00

right now, it will error I think

Alex Miller (Clojure team)15:05:35

it is, however, actually possible to resolve as maven artifacts include their git commit info at build time, making it possible to resolve the "newer" one via git commit comparison

Alex Miller (Clojure team)15:05:56

I have not actually done that work yet, but have done enough research to believe it's feasible


ah neat. thanks for the info!

Alex Whitt17:05:54

Yesterday I was asking about adding a self-signed SSL cert with tools.deps, and I did some research on it. I'm on NixOS, which is a functional / immutable OS, and as such its Java trust store is also immutable (read-only), so I can't just imperatively add the cert to the trust store using keytool. Unfortunately right now there's not a configuration option in NixOS to do this either. Am I SOL?