Clojurians
#boot
<
2015-11-17
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

flyboarder01:11:55

so It seems i have been able to get the app deployed to heroku!! needed to build uberjar but now jetty is giving a 404

flyboarder01:11:46

@micha what was the design decision around boot always pulling deps?

micha01:11:45

how do you mean "always pulling deps"?

flyboarder01:11:37

boot always goes through the process of pulling deps for a project (or at least checking for them) whenever it’s run

flyboarder01:11:06

is there a way to disable this?

micha01:11:40

what's the issue you're having?

micha01:11:56

i mean if you can't have dependencies then you must make an uberjar

flyboarder01:11:32

im not so much having an issue as it’s a huge ammount of time spent pulling deps for a container every time I want to test a change in build.boot

micha01:11:46

oh, you can cache the maven stuff

micha01:11:04

it's documented in the adzerk/boot-clj README i think

micha01:11:23

basically you set BOOT_LOCAL_REPO to some directory in your container

flyboarder01:11:42

ok i thought it already cached those

flyboarder01:11:11

yeah i moved all of my compiling to the task that the container runs

flyboarder01:11:23

the compiled uberjar is throwing a 404 but I can run it in dev?

micha01:11:08

for docker you can work in layers

micha01:11:15

so docker can cache things

flyboarder02:11:31

@micha got the uberjar working (cant quote the ns)

onetom05:11:43

hmm... im not getting any messages from the reload ring middleware when it's reloading namespaces. it's annoying because i can't even see compilation errors either. i was expecting to see them via castra at least but they dont appear there either

onetom05:11:13

i checked the example in the lein new hoplon-castra x generated project but that doesnt have any special setup, just uses (serve :reload true)

flyboarder05:11:36

@onetom: can you post the boot task

onetom05:11:47

(deftask dev
  "Build backends for development."
  []
  (let [nrepl-port 9999]
    (spit ".nrepl-port" nrepl-port)
    (comp (serve :port 3001
                 :reload true
                 :handler 'appboard.api/ring-handler
                 :nrepl {:port nrepl-port})
          (wait))))

onetom05:11:48

(def ring-handler
  (->
    (site #'routes)
    (wrap-defaults api-defaults)
    (wrap-castra
      'our.api 'some-more.api ...)
    (wrap-utf-8)
    (wrap-session
      (node-mongo-session (config :db) "sessions" "xxxxx"))
    (wrap-cors (re-pattern (str "^" (config :frontend-url) "/?$"))
               (re-pattern (str "^" (config :homepage-url) "/?$"))
               (re-pattern (str "^" (config :cockpit-url) "/?$")))))

flyboarder05:11:53

hmm actually im not seeing any difference when i change :reload to false

onetom05:11:33

it only does the reload when a request is sent

onetom05:11:39

not directly on filesystem change

flyboarder06:11:28

@onetom would have to ask @pandeiro about it

pandeiro10:11:42

@onetom Can you try 0.7.1-SNAPSHOT?

onetom10:11:11

@pandeiro: i will try tomorrow, thx!

pandeiro10:11:22

This was fixed recently

onetom10:11:31

we have actually looked into the patches and i saw u touched something around the reload

pandeiro10:11:41

Yeah @esp1 contributed that and if it works for you I'll cut a 0.7.1 release

jaen11:11:05

When I do require inside a deftask body I get a class not loaded error, when I do it outside everything works. Is that expected?

martinklepsch11:11:34

@jaen: not sure if this is what you’re looking for but came to mind reading your question

jaen11:11:56

Well, I haven't read this wiki page, but I'm doing exactly that. Maybe something else is wrong then.

jaen11:11:42

(deftask dev
  "Starts the development environment."
  []

  (require 'scrabble.backend.core)
  (let [system-var (resolve 'scrabble.backend.core/dev-system)]
    (comp
      ...)))

jaen11:11:52

Is what I'm doing, and when I try the same from REPL it seems to resolve

jaen11:11:56

Yet in the task I get

jaen12:11:04

Unable to resolve var: scrabble.backend.core/dev-system in this context

jaen12:11:17

Ok, nevermind, I thought I substituted the var quote for resolved var in the body of the task, which I didn't.

jaen12:11:36

I probably need to wake up or something. Sorry for the bother '

onetom16:11:07

@pandeiro: we have a split frontend/backend setup, so a, we use [jumblerg/ring.middleware.cors "1.0.1"] as shown above b, as your readme suggests, we just use wait instead of watch, unlike the hoplon-castra template shows as a result im just seeing errors, like:

POST  

XMLHttpRequest cannot load . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access. The response had HTTP status code 500.
so the backend error is not visible on the line of POST and i assume because of the lack of watch, i don't see the compilation error on the terminal either.

onetom16:11:22

it seems that the response with the error message doesnt have the CORS headers, but im not sure at which level is it stripped off i might try to debug it tomorrow with print-foo's middleware support maybe...

pandeiro17:11:29

@onetom I don't think wait/watch should matter. Are you sure you whitelist all the headers your using with the cors request? That's one possible gotcha.

domkm18:11:11

Has anyone experienced obscenely slow tests using boot-test? My tests run in a fraction of a second via CIDER but take almost a minute when part of a task pipeline with boot-test.

micha18:11:01

what else are you doing in the pipeline?

micha18:11:46

also what if you run the tests from the repl

micha18:11:59

or is that what you're doing with cider, basically?

domkm19:11:46

@micha: Yeah, testing from the repl is what I meant by cider. That's basically instantaneous. The pipeline is (watch) (speak) (test) (repl :server true)

micha19:11:16

seems pretty normal

micha19:11:35

are you on java 7 or 8?

juhoteperi19:11:38

Hmm doesn't boot-test run the tests on a fresh pod each time?

juhoteperi19:11:07

It will be really slow when compared to just reloading one ns and running the tests

juhoteperi19:11:04

Or even when compared to reloading the changed ns (via c.t.n or ns-tracker)

domkm19:11:05

@juhoteperi: Even specifying that tests should be run on specific namespaces is awfully slow

domkm19:11:22

...via boot-test task options

juhoteperi19:11:41

Yeah it will reload all the namespaces where the specific namespace depends on

juhoteperi19:11:48

or not reload, but just load

juhoteperi19:11:03

because boot-test uses completely empty pod each time

domkm19:11:35

Is it this slow for everyone could there be something pathologic with my system? I don't think anyone would use boot-test if this was the norm.

juhoteperi19:11:54

I don't use boot-test for development, only for CI

domkm19:11:58

My code base is tiny and tests take a minute to run

juhoteperi19:11:32

Well, that doesn't sound normal

martinklepsch19:11:14

Used boot test recently with watch and it was super snappy

micha19:11:55

maybe large fixtures need to be recreated

martinklepsch19:11:58

Does the test namespace require any slow to compile namespaces?

domkm19:11:01

fixtures: It's a datomic in-memory test. Only a single conn is created and all tests are run using with so I doubt that is a major time hog.

domkm19:11:09

slow requires: I'll check

micha19:11:31

it's starting with a fresh pod each time, remember

micha19:11:40

so datomic won't survive a reload

micha19:11:12

nothing is shared from one test run to the next

domkm19:11:59

@micha: Understood. However the fixture loads instantaneous by my perception (so a few hundred ms at most) and is only run once per ns. It might contribute a few seconds in total to the test time but I don't think it accounts for the total time. I'm trying to start a repl to test recompiling dependent namespaces but am having network issues. Will check back later when I get it working.

domkm19:11:45

Hmm, this is weird. When I run the tests fresh in a repl it takes a few seconds. Fine. However, when I put :reload-all in the main test ns and reevaluate the namespace, I get a compiler exception NPE from within core.async