This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-02
Channels
- # 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
, 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 deps.edn
and :dependencies
if you use -B
.
@martinklepsch https://github.com/boot-clj/boot/issues/650 looking to compare lein / boot uberjar build times on linux... see if this is an OSX issue or not
However, 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 uber
).
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.
deps
loads all the deps.edn
files -- three of them by default.
The system one, the home directory one, and the project one.
The whole point of boot-tools-deps
is to mimic clj
s behavior.
It assumes you have "no" :dependencies
(well, except boot-tools-deps
perhaps)
If that’s the case, then why does boot deps test
and boot deps -A test test
both fail for :deps
and :extra-deps
?
Specifically you can run boot -d seancorfield/boot-tools-deps deps repl
in a project with no build.boot
and it'll behave like clj
.
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.
@seancorfield do you usually deploy using an uberjar?
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 clj
@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...
(if I can come up with a suitable --q-something
name)
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.
FYI, 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?
@bhauman what do you mean raw terminal?
REPLy has to be launched from a jvm process that was directly launched from a terminal.
oh, so there should be boot.repl-client
the file for the server is instead here: https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/repl_server.clj
but it it tied to boot
ah yes there is client and server side
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?
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
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)
it happens after the tests have completed.Although, in this case
Caused by: java.io.IOException: Stream closed, compiling:(clojure/core_instant18.clj:15:1)
which is about the only time I ever see that exception... So, yeah, definitely a Boot pod quirk if you ask me...I think so.
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 future
.
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.
Thanks 🙂