Fork me on GitHub
#boot
<
2018-08-03
>
petrus09:08:22

Hi Bootleggers, I hope this helps someone: I published a little Cljs tool that translates boot-clj and Leiningen :dependencies to the newer deps.edn format: https://theronic.github.io/depsy/ (source on GitHub).

dominicm11:08:54

I don't think :scope applies in deps.edn

dominicm11:08:54

it should probably generate a test alias or something

seancorfield19:08:54

Well, :scope does apply but the Maven libraries don't handle it in the way you might expect in all cases 🙂 The recommendation is to not use :scope and, as @ says, to use aliases instead.

seancorfield19:08:04

Is anyone testing Boot-based systems on Clojure 1.10.0 Alpha 5 or later? We tried to switch up to 1.10.0 Alpha 6 and ran into problems with pods (particularly pod refresh). We have occasionally had problems with ClassNotFoundExceptions with pods in the past -- infrequent, random occurrences which almost always go away on a subsequent run -- but with 1.10.0 Alpha 5/6 we are hitting CNFE reliably and repeatedly on a particular pod refresh in the middle of a long pipeline of tasks (that all work just fine when run independently).

seancorfield19:08:43

For now we just backed off to 1.9.0 but at some point we'll move to 1.10.0 and just break our pipeline into separate pieces as a workaround I expect (we're looking to switch to deps.edn/CLI tooling where possible at some point, but that's currently a long way off).

alexmiller19:08:20

sounds like a textbook case where there is a race condition that (due to a change in performance of other pieces) has suddenly been made common

alexmiller19:08:46

I will carefully avoid pointing a finger (as it may end up pointing at me)

alexmiller19:08:37

there are some data race detectors out there (like YourKit). I wonder if it would be possible to get any value out of them in the case that you have that sometimes fails.

seancorfield19:08:19

The pre-1.10 failures are very rare, but also include a case I didn't mention, where loading core_instant18.clj fails -- and a subsequent run immediately succeeds. (I mention it only because of that cropping up in another classloading context the other day -- and I'm not certain it's directly related to the pod refresh issue).

seancorfield19:08:45

With 1.10, the problem occurs only in the middle of a long task pipeline and always on a particular task setup. Since it's for a set of WebDriver-based tests against a legacy app, we don't have much motivation to fix it since we'll be decom'ing that app soon anyway (possibly before we move to 1.10).

seancorfield19:08:58

I'm mostly just curious as to whether I'm the only person trying to use Boot pods with 1.10 "in anger" -- and whether this is a problem with Boot pods and 1.10 or a problem with our usage of Boot pods that 1.10 just makes worse...

alexmiller20:08:38

the loading of core_instant18.clj depended on a class existence check against java.sql.Timestamp, which kinda makes you wonder if there is some sort of classloading race condition around that.

alexmiller20:08:04

certainly I have seen race conditions around concurrent load of the same ns with state (in particular, there was an issue around clojure.spec.gen.alpha and it’s dynaloading of the test.check generators ns)

alexmiller20:08:13

might be interesting to try a patch from the latter in a long run to see if it changed the behavior

alexmiller20:08:32

but I am really just fishing in the dark

hmaurer23:08:37

Quick question: how does Clojure’s internal handling of deps (https://clojure.org/guides/deps_and_cli) fits with something like boot?