This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (72)
- # boot (68)
- # cider (51)
- # clara (20)
- # cljs-dev (44)
- # cljsrn (7)
- # clojure (168)
- # clojure-brasil (1)
- # clojure-dev (48)
- # clojure-greece (2)
- # clojure-nl (29)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (28)
- # clojurescript (2)
- # cursive (9)
- # datascript (1)
- # datomic (105)
- # dirac (1)
- # docker (2)
- # duct (11)
- # emacs (19)
- # events (1)
- # figwheel (1)
- # fulcro (23)
- # garden (4)
- # graphql (5)
- # hoplon (46)
- # jobs (5)
- # juxt (13)
- # leiningen (6)
- # lumo (12)
- # off-topic (29)
- # parinfer (5)
- # re-frame (7)
- # reagent (6)
- # ring (2)
- # sql (5)
- # yada (6)
@seancorfield Doh. Thanks for the reminder on what good bug reporting means. Updated: https://github.com/grzm/ex.boot-tools-deps-alt-test
@grzm OK, the
boot test examples work exactly as I would expect (with
deps -B, deps -A test`, and
deps -A test -B) -- note that if you do
boot deps -A test repl, all three deps are on the classpath and can be loaded, but
boot-test creates a pod based on
:dependencies, so for it to correctly build the pod, you need to tell
deps to update
:dependencies -- and because it deliberately overwrites the original dependencies with the new ones from
deps.edn files, you lose the component dep. So that's working exactly as designed -- even if it isn't what you wanted 🙂 You can't mix'n'match dependencies from
:dependencies if you use
boot alt-test fails when you use
-B (but is otherwise "as expected") because, I think, it doesn't load its
impl namespace until it's about to run the tests and it doesn't add itself to the pod it creates because it assumes it's already loaded. Since
boot-test relies only on
clojure.test which is still loaded in Clojure itself, I think it's "immune" to the dependency overwrite.
I think the solution to this is to provide a variant of
-B that adds to
:dependencies rather than completely overwriting them -- with the caveat that you won't be able to run
uber in the same pipeline (because
boot-tools-deps itself, plus other cruft, will be dragged into the
That will essentially allow you to restore the pre-0.2.0 behavior, buggy as it was, to allow you to work with tooling that lazy loads itself...
Yeah, that makes sense. Though, it’s not clear to me why that wouldn’t be the default behavior.
You get all sorts of weirdness if you add to
:dependencies -- transitive dependencies don't respect
:scope etc etc. So it's much safer for that to not be the default.
If that’s the case, then why does
boot deps test and
boot deps -A test test both fail for
Specifically you can run
boot -d seancorfield/boot-tools-deps deps repl in a project with no
build.boot and it'll behave like
They "fail" because they add to the classpath, not
:dependencies -- and
boot-test builds a pod from
:dependencies, regardless of what is on the classpath.
What I clearly need to explain in the README is that
boot-tools-deps is meant to add Boot functionality to
clj -- and your project should execute completely with just
@minikomi Mostly, we deploy as uberjars, yes. Although, for reasons, we also still deploy source and have a couple of processes that essentially just run
boot some-task and pull everything in from source.
right.. looking to deploy web app, and finding uberjar building with boot much slower than when i was using lein
@grzm I'll probably call it
-Q so folks understand it's potentially not "just" a merge...
OK, I need to go do chores. And maybe get some beer. We had to put a kitty to sleep today and my wife & I are pretty sad and will probably drown our sorrows a bit.
boot-tools-deps 0.3.0 is available -- adds a
-Q option to perform a "quick merge" of
deps.edn dependencies into Boot's
:dependencies which will "solve" most tool chain issues folks are seeing (but
-B will still be needed for
uber). /cc @grzm
is there a boot trampoline? or rather how to you run a process like REPLy in the raw terminal? (Writing some docs for my new readline library)
@seancorfield Thanks for the rapid turnaround! I’ve updated the repo README reflecting the changes both in 0.3.0 and my understanding. I did find that
boot deps -Q test fails about half the time with an
ErrorInitializerException (stacktrace and environment included in the README).
Interesting. I ran that command about 20 times and never saw an exception. I'm using JDK 8 -- looks like you're using JDK (based on those reflective call warnings)? I wonder if that affects it @grzm?
REPLy has to be launched from a jvm process that was directly launched from a terminal.
the file for the server is instead here: https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/repl_server.clj
FWIW, I have occasionally since similar exceptions inside ShimDandy and it's usually due to asynchronous pod cleanup (so a pod gets shutdown in a future after some classes it needed have gone away)
So I'd be inclined to chalk that up to a quirk in Boot itself (specifically in its pods).
Re: the initializer exception, it might be mitigated if I changed
(future (pod/destroy-pod pod)) to just
(pod/destroy-pod pod) but it would slow things down a bit...
Ah! Repro'd it
it happens after the tests have completed.
Exception in thread "Thread-18" java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:344) at clojure.lang.RT.classForName(RT.java:2204) at clojure.lang.RT.classForName(RT.java:2213) at clojure.lang.RT.loadClassForName(RT.java:2232) at clojure.lang.RT.load(RT.java:450) at clojure.lang.RT.load(RT.java:426) at clojure.lang.RT.doInit(RT.java:468) at clojure.lang.RT.<clinit>(RT.java:336) at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.init(ClojureRuntimeShimImpl.java:23)
Although, in this case
which is about the only time I ever see that exception... So, yeah, definitely a Boot pod quirk if you ask me...
Caused by: java.io.IOException: Stream closed, compiling:(clojure/core_instant18.clj:15:1)
So, I checked the time spent in
destroy-pod and it's negligible so I might remove that
future anyway. For reference, on my Mac, creating the pod takes 1.8-1.9 seconds but destroying it only takes about 3ms, so not worth a
Yeah, I've never been able to get it a reproducible case since it's a race condition somewhere in some cleanup code 😞
Thanks again for the quick turnaround. I’m a big fan of boot-new, clojure.java.jdbc, and now boot-tools-deps.