Fork me on GitHub

Found this today. It appears -X:deps gets tricked by a user.clj on the path that requires a namespace that is on the project classpath but not on the classpath that -X:deps itself uses? Is this expected? Is there any better way to handle this than adding something like -Sdeps '{:aliases {:no-paths {:replace-paths []}}}' -A:no-paths?

; # enviroment
; clojure -Srepro -version
Clojure CLI version
; # deps & source
; echo '{:paths ["src"] :deps{org.clojure/java.classpath {:mvn/version "1.0.0"}}}' > deps.edn
; mkdir src && echo '(ns user (:require' > src/user.clj
; # launch repl
; clj -Srepro
Clojure 1.10.3
user=> (find-ns '
#object[clojure.lang.Namespace 0x21325036 ""]

; # check deps
; clojure -Sforce -Srepro -X:deps list :license :none
Exception in thread "main" Syntax error compiling at (user.clj:1:1).
	at clojure.lang.Compiler.load(
	at clojure.lang.RT.loadResourceScript(
	at clojure.lang.RT.loadResourceScript(
	at clojure.lang.RT.maybeLoadResourceScript(
	at clojure.lang.RT.doInit(
	at clojure.lang.RT.init(
	at clojure.main.main(
Caused by: Could not locate clojure/java/classpath__init.class, clojure/java/classpath.clj or clojure/java/classpath.cljc on classpath.
	at clojure.lang.RT.load(
	at clojure.lang.RT.load(
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(
	at user$eval138$loading__6737__auto____139.invoke(user.clj:1)
	at user$eval138.invokeStatic(user.clj:1)
	at user$eval138.invoke(user.clj:1)
	at clojure.lang.Compiler.eval(
	at clojure.lang.Compiler.eval(
	at clojure.lang.Compiler.load(
	... 6 more
; # check deps with workaround
; clojure -Sdeps '{:aliases {:no-paths {:replace-paths []}}}' -A:no-paths -Sforce -Srepro -X:deps list :license :none
org.clojure/clojure 1.10.3
org.clojure/core.specs.alpha 0.2.56
org.clojure/java.classpath 1.0.0
org.clojure/spec.alpha 0.2.194

Alex Miller (Clojure team)13:01:09

You could use -T:deps instead here


ooh let me read up on that


that's actually proving to be a challenge to google for, do you happen to have a link to where I can get more info?


Thank you!

Alex Miller (Clojure team)16:01:56

but fyi, I have fixed the :deps alias for next release so -X:deps will be fine


Saw the commit, thank you for that!

Alex Miller (Clojure team)15:01:48

not sure the second is any more interesting :)


Ha! Maybe not. Have not experienced this issue myself yet, and seeing it twice so close together made me wonder. Could be just sheer luck.

Alex Miller (Clojure team)16:01:37

yes, it's just a timing thing. buried in the guts of the maven stuff there is an unsynchronized collection being updated. if you happen to hit it in two threads simultaneously, it will blow up. mutable shared data is no fun and no fun to fix.

👍 1
Alex Miller (Clojure team)15:01:05

it's useful thanks, I've reopened TDEPS-153 and I'll take a look when I get a chance

👍 1