boot 2017-05-30 | Slack Archive

djebbz08:05:18

Hello folks. I'm trying to run CLJS tests that require a browser env. I tried boot-cljs-test but got some error doo is undefined when running under firefox. I feel like Doo and Karma are a bit overwhelming, and both doo and boot-cljs-test seem outdated with regard to Karma versions. Or not ? Am I wrong ? How do you do ?

pandeiro16:05:47

Wondering how other boot folks produce something similar to the env/dev/config.edn, env/prod/config.edn approach with lein + profiles

dominicm16:05:05

@pandeiro I don't understand the question. If you're using uberjars, lein profiles don't apply for prod, no?

dominicm16:05:51

generally though, I'd pass in the config file to my "system" as an option. Then -main will use the prod one, and (dev) will pass the "env/dev/config.edn"

pandeiro16:05:36

@dominicm Thanks yeah that makes sense; what I meant was yes the :dev profile lein has, and then in production maybe a deployment tool knows how to find the prod version and put it on the classpath or in a determined location

dominicm16:05:05

@pandeiro if you want my slightly biased advice. I would advise using Aero & having only one config file 🙂

dominicm16:05:17

(I work at JUXT, but used Aero before I joined)

pandeiro16:05:41

Oh that's cool, I was looking at using cprop but let me take a look at Aero

dominicm17:05:25

pandeiro: cprop is cool. It takes a merging approach, which can sometimes be unexpected, especially as everything in the config can be overriden by env variables. We've found (at least for the kinds of projects we've worked on!) that there's usually a handful of environment variables you need to actually get from the environment. In aero you'd do something like this in your config file:

{:port #long #env PORT}

You can do a fallback with #or:

{:port #long #or [#env PORT, "1000"]

You communicate something different in each case: 1. This variable always comes from the environment 2. This variable sometimes comes from the environment The explicitness is very useful when debugging.

pandeiro17:05:29

Yeah I'm liking that DSL in aero, very cool

pandeiro17:05:51

I think we may have a requirement for this project on using system properties for some config

dominicm17:05:08

You might find Aero a little cumbersome if you need to deploy into an environment where someone will arbitrarily want to override everything via an environment variable though. We work in environments where we know exactly what has to come from the environment.

dominicm17:05:30

system properties, hmm, we should support that. If we don't, the PR should be really simple.

pandeiro17:05:15

This is great in that it has now become clear that I don't know exactly what the requirements are for the config piece 🙂

pandeiro17:05:31

Thanks for the help!

dominicm17:05:45

https://github.com/juxt/aero/blob/master/src/aero/core.cljc#L52-L55 ^^ implementation for reading java system properties, if this is what you meant 🙂

dominicm17:05:10

Looking through the cprop source, it looks like the merging could easily be: 1) part of aero (though anti-philosophy really) 2) merged after calling out to aero It's one or two functions deep to pinch it out by the looks of it 🙂

pandeiro16:05:54

No shortage of libs in the clojure configuration space 😉

ghosttoaster20:05:54

Does anyone one know whats up with "user/clojuredocs" in boot repl? the clojuredocs function just throws an error about not being able to find a clojuredocs client. Do I need to do something to set it up?

2017-05-30

Channels