Fork me on GitHub
#boot
<
2018-02-02
>
grzm01:02:24

@seancorfield Doh. Thanks for the reminder on what good bug reporting means. Updated: https://github.com/grzm/ex.boot-tools-deps-alt-test

seancorfield02:02:39

@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.

minikomi02:02:15

@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

seancorfield02:02:30

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.

grzm02:02:39

Yeah, -B works as I expect (other than the errors with alt-test)

seancorfield02:02:47

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).

seancorfield02:02:36

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...

grzm02:02:36

Yeah, that makes sense. Though, it’s not clear to me why that wouldn’t be the default behavior.

grzm02:02:54

-B overwrites, of course.

grzm02:02:25

If you don’t want deps, you don’t include deps.

grzm02:02:42

I’m not clear what deps with no flags actually does.

seancorfield02:02:43

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.

seancorfield02:02:59

deps loads all the deps.edn files -- three of them by default.

seancorfield03:02:10

The system one, the home directory one, and the project one.

seancorfield03:02:30

The whole point of boot-tools-deps is to mimic cljs behavior.

seancorfield03:02:56

It assumes you have "no" :dependencies (well, except boot-tools-deps perhaps)

grzm03:02:16

If that’s the case, then why does boot deps test and boot deps -A test test both fail for :deps and :extra-deps?

seancorfield03:02:31

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.

seancorfield03:02:20

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.

minikomi03:02:25

@seancorfield do you usually deploy using an uberjar?

minikomi03:02:36

sorry, slipped haha

seancorfield03:02:11

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

grzm03:02:54

So, yeah, -M or something to merge would provide the pre 0.2 behavior.

grzm03:02:09

-A is wonderful, by the way. Thank you!

seancorfield03:02:10

@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.

minikomi03:02:41

right.. looking to deploy web app, and finding uberjar building with boot much slower than when i was using lein

seancorfield03:02:59

@grzm I'll probably call it -Q so folks understand it's potentially not "just" a merge...

seancorfield03:02:15

(if I can come up with a suitable --q-something name)

grzm03:02:17

What’s the mnemonic?

seancorfield03:02:07

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.

dave16:02:45

my condolences, sean. losing a loved pet is hard

grzm03:02:41

Thanks for the insight, Sean. Much appreciated.

seancorfield20:02:02

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

bhauman21:02:36

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)

grzm21:02:54

@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).

seancorfield23:02:08

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?

richiardiandrea21:02:29

@bhauman what do you mean raw terminal?

bhauman21:02:24

REPLy has to be launched from a jvm process that was directly launched from a terminal.

bhauman21:02:37

not an intermediate process

richiardiandrea21:02:10

oh, so there should be boot.repl-client

bhauman21:02:35

you guys already use reply though right?

bhauman21:02:23

if I wanted to launch a program that had reply in it, is it possible?

richiardiandrea21:02:10

but it it tied to boot

bhauman21:02:37

ok I found boot.repl-client

richiardiandrea21:02:38

ah yes there is client and server side

seancorfield23:02:08

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?

seancorfield23:02:14

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)

grzm23:02:16

Could be.

seancorfield23:02:43

So I'd be inclined to chalk that up to a quirk in Boot itself (specifically in its pods).

grzm23:02:09

There are some levels of magic I’ve not yet attained.

grzm23:02:45

The JDK, Java version numbering is now consistent, right? JDK 8 is Java 8?

grzm23:02:20

Yeah, I’m on 9.0.4

seancorfield23:02:48

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...

seancorfield23:02:59

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.

seancorfield23:02:02

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...

grzm23:02:40

Where would an appropriate ticket go? Boot itself?

grzm23:02:32

I’m not sure how to whittle this down into a better repro case.

seancorfield23:02:48

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.

seancorfield23:02:14

Yeah, I've never been able to get it a reproducible case since it's a race condition somewhere in some cleanup code 😞

grzm23:02:09

Yeah, when I saw that it wasn’t consistent, I shuddered a bit.

grzm23:02:34

Thanks again for the quick turnaround. I’m a big fan of boot-new, clojure.java.jdbc, and now boot-tools-deps.

seancorfield23:02:44

Thanks 🙂