@pandeiro: sure. all castra calls work normally, but when i make a syntax error, the next castra call fails because the response doesnt have anything else but the exception stack trace, not even a http header

@domkm: loading the datomic api takes quite a while

We experience 4-7second runtimes w in-mem datomic db

I would recommend u to try the most minimal boot-test scenario to see how it can run with sub-second speeds and u will see what happens when u add datomic.api to the mix

@domkm: try to comment out this line and see what happens before and after on subsequently saving test.clj: https://gist.github.com/onetom/2e39f464df438b5e69b0#file-test-clj-L3

on my i5 rMBP it takes 0.1s without datomic and takes 3s with datomic

so much about the promise of having an in-memory db making tests fast

@onetom: Ouch, that's a bummer. I still don't think it's solely to blame though because the test suites runs in <10 secs in a fresh repl so a fresh pod shouldn't (I hope) take 60 secs.

@onetom: In terms of datomic, maybe there is a way to have a fixture run once for the whole test suite instead of once per namespace.

it's not the fresh pod which takes long to create but to load the datomic.api into it

seems like you already have a good workflow with cider for rapid development and boot-test for CI

that seems like a pretty good way to do it

that's pretty much what i've been doing, too

@domkm: just try to do a (require 'datomic.api) from a boot -BP -d com.datomic/datomic-free:0.9.5327 repl it does take ~3s

@micha: i vaguely remember something like u can "fork" an existing clojure env and make a new pod based on it am i mixing it up with something else? like would it be possible to specify to preload certain stuff into the test pod which we trust not to change between test runs?

it doesn't copy the stuff in memory, only the dependencies and jvm configuration

there is no way to share clojure objects between pods

because of the way protocols work it's impossible

u r reloading clojure itself too, right?

yep

you can mitigate all of this with the pod-pool, which maintains of pool of warmed up pods ready to go

the boot-test task uses one

how would that help? between test runs there is enough time to create 10 other which already have the dependencies loaded into them?

i would hope so

any example on how to do this?

if you need to test your thing every < 3 seconds i would say there is something wrong

and you can bump up the size of the pool to handle spikes

boot-test does this

it preloads clojure in the pod

but you could preload more, like datomic

the only issue is if the stuff you preload needs to change when you work

then of course it won't work the way you want

where can i specify what to preload?

there is an :init option to pod-pool where you can make a constructor

https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L48

https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L11-L27

pod-pool takes a :size option as well, i believe

which you can use to increase the number of pods in the pool

how can i override that :init ?

using something like with-redefs?

we should add the option to the boot-test task

or should i just fork boot-test and...

that

👍 totes

it could take a symbol

and resolve that to get the init fn you want to use

or something

im not very confident in this area yet still... havent used (resolve) yet in any real scenario..

but anyway, no worries, i can hack something specific up for ourselves 1st

it will be really usable if we can shave off that 3 seconds!

the problem w the 3 seconds is not that we want to run tests that frequently, but we want to continue thinking after we made a change in the tests, so we want to know whether that change was successful or not

right

have you tried running the tests in the repl, like with cider?

no, why?

but kenneth says maybe we should not be drinking (cider) while trying to run tests.

he is the irish person on the team 😉

hahaha

drinking seems to help when i run tests

kenneth will come over and test that hypothesis w u

and we shall formally include it into our development practices then

@micha: seems the boot-clj docker images fails to build a heroku-valid slug via heroku docker:release

do you know what the issue might be?

working on it

the log was fairly useless

im going to rebuild the boot-clj from the heroku/jvm image

it would be a shame if you needed to use a special image to deploy to heroku

seems like it would kind of defeat the purpose of using docker

You need to inherit from heroku/jvm

Or at least heroku/cedar:14

yeah that what i figured

thanks 😉

I would argue that its a drawback of docker though :)

what is the problem that you are not able to use other images?

Because it ultimate is executed on our LXC runtime and not a docker runtime

We will probably get to a true docker runtime. No promises though :)

does the heroku/jvm image work normally with docker?

Yea

sweet

@codefinger: does the cedar:14 stack have wget or do i need to install everything as per usual?

No wget i think. But does have curl

Its exactly what you get when you run heroku run bash, so you could test things out that way

initial commit is looking promising, its building now

Is there anything like lein-ancient for boot?

boot show -u

Thanks! That seems to work pretty darn well 😉

Beginner question: where is that documented?

:thumbsup:

boot show --help or (doc show) in the repl

to see all the tasks that are available at any time you can do boot --help

or (boot) in the repl

Brilliant!

you might also want boot show -d and boot show -p

like lein deps :tree sort of

Yeah! I found those guys here: https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users

But the boot show -u is new to me.

show is where the project diagnostic tools are

And, I presume, the process of copying the output of boot show -u to my build file is up to me?

yeah

nod easy enough!

you can make a deps.edn file

if you want

and slurp that in in your build.boot

or something

Right, and then just write a task to update that..?

but it's not really feasible to write to the user's build.boot file because it's a program

yep

Coo coo

Micha, are you one of the boot devs on the off chance? Or just a plucky adventurer like myself?

yeah i've been working on it for a while now

Well, major kudos to you for the effort. I'm tremendously fond of boot so far, and am really excited to learn all about it.

here is the place, btw: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L197

if you wanted to get the update dep info as clj data

you can call that function from the repl

that's awesome

and make a task that updates your deps.edn file or whatever you want to do

thanks! i'm glad you are enjoying it

@codefinger: is there something else I need to do to get the docker:release to work? it fails to find the slug.tgz

@micha here's the repo for heroku docker image it seems if there is an entry point in the docker file it will fail to build the slug

https://github.com/degree9/heroku-boot-clj

https://github.com/degree9/heroku-boot-clj

hey everybody I'm starting to migrate a lein project to boot. no questions, just wanted to say that I'm very impressed by the docs, both quality and quantity. awesome work

👍 that’s great to hear

boot-cljs do not support react-native

@isaac: is that a question or a statement? I know people building react-native apps with boot/boot-cljs

boot-cljs compiler js can’t running on iOS

It’s contains document.write …

the output file content difference with lein-cljsbuild outputed

@isaac: I see what you mean

@isaac: how should a loading shim for React Native look?

@isaac: can you more specifically say where the document write call is done? also make sure your lein-cljsbuild + boot-cljs compiler options are equivalent

I see that in boot-cljs :output-to is ignored. What is the usual way of getting the files to resources/public/... where I want them?

Oh! I’m sorry, my :asset-path set wrong

@martinklepsch: thanks

@bensu in boot-cljs you generally specify output location by putting the appropriate .cljs.edn file where you want it

the (README) documentation for this sucks, putting this kind of stuff in a file however has huge advantages (other tasks can look at/modify it)

@isaac: cool, glad you got it working. Would be curious to see a nice/minimal boot + react native setup if you have it

I'm sold on having a cljs.edn but I'm not sure about placing a config file on the same directory than generated files.

I would want to ignore/delete the generated files but track/keep the cljs.edn, which is awkward if they are next to each other

@martinklepsch: OK,

(this is just the “same directory” in target/ — just to be clear)

@bensu: generated files will never pollute your source tree

everything happens in fileset and is eventually dumped to target/

I'm serving files out of resources/public/... and I would like the js files to end in resources/public/js/generated.js

do I have to grab the files and move them there with a task?

I think I'm going to play with tenzing before migrating a project

seeing how it should work will probably help

@bensu: why not serving from target/public/?

because I hadn't realize that is how (serve) works

I'm now trying tenzing (AWESOME) and I see how it is supposed to work

@bensu: at the end of running the task pipeline boot dumps the fileset contents in :target-dir (defaults to ./target/)

yeah, but does it also dump all your files in resources there and "merges" the dirs?

many people also just serve stuff straight from the classpath (fileset is on classpath)

@bensu: the initial fileset is computed from the files you have in resource-paths, source-paths &c.

haha genius

these you need to set like (set-env! :resource-paths #{“resources”}) of course

@martinklepsch: is there a way to name the final file app.js both form my dev and production builds and be placed on the same place (to keep the same script tag on the html)?

@bensu: is something preventing you from using the same .cljs.edn file?

they are completely different

(as in every field)

you can use the sift task to move a file… boot sift -h

how are they so different though?

can I just leave it empty and pass all the options from the task?

@bensu: there’s a table in the readme what can be passed to task and what must be .cljs.edn — think most stuff can be done at task level

https://github.com/adzerk-oss/boot-cljs#options

@martinklepsch: thanks! I can, the options I'm interested are all compiler options. In tenzing, the file is called app.cljs.edn but the generated file is app.js

in my project the generated file is app.cljs.edn.js

is that related to the :ids?

how do you specify :ids?

@bensu: given you can set all things as task options you can use a single .cljs.edn file yes?

yes, it was a bad :ids.

I'm guessing boot-cljs magically finds the .cljs.edn file

it scans the fileset for .cljs.edn files yes.

one thing that I don't like is that as long as boot-cljs doesn't follow the compiler out convention you will always need an :asset-path for :none

That said value of :ids should always have .cljs.edn trimmed

ahh, good to know

I guess that :asset-path requirement depends on where you serve your files from. I assume the reasoning was that multiple builds need multiple output dirs(?)

yeah, it's not such a biggie either since these things are usually sorted out by the fine people that make templates

not all things are greenfield

@flyboarder: still having trouble with the docker stuff? have you tried putting the boot step in an ONBUILD RUN?

@codefinger: I got it deploying finally

https://github.com/degree9/heroku-boot-clj/blob/master/Dockerfile

if you have suggestions PR’s welcome

using the heroku base image was much simpler than i thought getting all the env setup would be

just updating circleci for running tests in docker

cool!

i'll pull it down and give it a try

i had to remove the entry point from the docker file so you will need to run boot <task>

an ONBUILD step would probably work. that's what i do with the lein image https://github.com/heroku/docker-clojure/blob/master/Dockerfile#L16

i also had to remove VOLUME

moving these things to docker-compose file resolves the issue

i didnt need VOLUME for my web service so having it only in shell instead of the dockfile is cleaner IMHO