This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-31
Channels
- # announcements (1)
- # aws (4)
- # babashka (40)
- # beginners (89)
- # calva (13)
- # cider (3)
- # clj-kondo (36)
- # cljdoc (16)
- # clojure (74)
- # clojure-boston (1)
- # clojure-dev (7)
- # clojure-europe (30)
- # clojure-new-zealand (1)
- # clojure-nl (17)
- # clojure-uk (5)
- # clojurescript (16)
- # core-async (9)
- # cursive (16)
- # datahike (3)
- # datalog (6)
- # datascript (7)
- # datomic (15)
- # emacs (38)
- # events (2)
- # figwheel-main (3)
- # fulcro (6)
- # google-cloud (18)
- # graalvm (6)
- # gratitude (1)
- # honeysql (1)
- # introduce-yourself (1)
- # jobs (1)
- # leiningen (5)
- # lsp (6)
- # malli (11)
- # meander (2)
- # off-topic (4)
- # re-frame (6)
- # reitit (8)
- # releases (2)
- # remote-jobs (3)
- # reveal (4)
- # shadow-cljs (200)
- # sql (8)
- # tools-deps (16)
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 1.10.3.1069
;
; # deps & source
;
; echo '{:paths ["src"] :deps{org.clojure/java.classpath {:mvn/version "1.0.0"}}}' > deps.edn
; mkdir src && echo '(ns user (:require clojure.java.classpath))' > src/user.clj
;
; # launch repl
;
; clj -Srepro
Clojure 1.10.3
user=> (find-ns 'clojure.java.classpath)
#object[clojure.lang.Namespace 0x21325036 "clojure.java.classpath"]
user=>
; # 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(Compiler.java:7652)
at clojure.lang.RT.loadResourceScript(RT.java:381)
at clojure.lang.RT.loadResourceScript(RT.java:368)
at clojure.lang.RT.maybeLoadResourceScript(RT.java:364)
at clojure.lang.RT.doInit(RT.java:486)
at clojure.lang.RT.init(RT.java:467)
at clojure.main.main(main.java:38)
Caused by: java.io.FileNotFoundException: Could not locate clojure/java/classpath__init.class, clojure/java/classpath.clj or clojure/java/classpath.cljc on classpath.
at clojure.lang.RT.load(RT.java:462)
at clojure.lang.RT.load(RT.java:424)
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(RestFn.java:408)
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(RestFn.java:142)
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(RestFn.java:137)
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(RestFn.java:408)
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(Compiler.java:7181)
at clojure.lang.Compiler.eval(Compiler.java:7170)
at clojure.lang.Compiler.load(Compiler.java:7640)
... 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
asked at https://ask.clojure.org/index.php/11522/x-deps-might-fail-when-user-clj-requires-something too
You could use -T:deps instead here
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?
https://clojure.org/reference/deps_and_cli#_aliased_tool_execution
but fyi, I have fixed the :deps alias for next release so -X:deps will be fine
Reminds me of this one I opened some time ago btw: https://ask.clojure.org/index.php/9947/could-replace-deps-imply-replace-paths-by-default
@alexmiller cljdoc CI https://app.circleci.com/pipelines/github/cljdoc/cljdoc/280/workflows/4e0f40cf-1b73-48a9-9f35-2ab8d0096466/jobs/3337?invite=true&invite=true#step-109-4 issue https://clojure.atlassian.net/browse/TDEPS-153 using v1.10.3.1058. But without a reproducible use case, I’m not sure how much value that is to you.
Interesting maybe @alexmiller: https://app.circleci.com/pipelines/github/cljdoc/cljdoc/282/workflows/829be0b5-171f-48fb-9228-6cadb5f476ad/jobs/3348?invite=true#step-108-4 under same environment.
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.
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.
it's useful thanks, I've reopened TDEPS-153 and I'll take a look when I get a chance