juxt

2017-06-05T13:36:04.429958Z

Anyone know the best way to set environment variables when testing when you use aero? Usually weโ€™ve used environ and set environment variables in .profiles.clj when testing. Is it best to just also include environ?

dominicm 2017-06-05T14:37:27.690452Z

@shan You can use #env tag

dominicm 2017-06-05T14:37:55.700381Z

If you need fallbacks, you can do this: #or [#env FOOBAR :fallback]

2017-06-05T14:43:32.823226Z

Thanks @dominicm. Thatโ€™s fine for loading the env vars but we want to be able to set some env vars for local development. Usually weโ€™d do this with .profiles.clj and use environ. Our main problem is that we want to load different configs depending on what an environment is set as (say we have region ENV VAR). This env var can be set up using consul in our prod and pre-prod environments but I was wondering how weโ€™d set this in our local dev environments. We also want to throw an exception if that env var is not set.

2017-06-05T14:43:57.832600Z

Could possibly be going about solving this problem in the wrong way tho

dominicm 2017-06-05T14:45:12.860495Z

@shan: I'd recommend the #profile tag in that case ๐Ÿ™‚.

dominicm 2017-06-05T14:51:09.992161Z

When you call into aero, you can provide the profile as a value. Your get-profile would perhaps look like this:

(defn get-profile []
  (doto (keyword (System/getenv "region")) assert))

(aero/read-config (io/resource "config.edn") {:profile (get-profile)})
Then in config.edn:
{:db-url #profile {:prod "<ddb://prod/foobar>"
                   :dev "ddb:<mem://myapp>"}

dominicm 2017-06-05T14:51:13.993368Z

@shan ^^

2017-06-05T14:53:05.035155Z

๐Ÿ‘ how would you go about setting the region env var locally?

dominicm 2017-06-05T14:59:56.189729Z

@shan Generally, I don't. In the dev/dev.clj file, we call (new-system :dev).

2017-06-05T15:00:09.195798Z

ah ok

dominicm 2017-06-05T15:00:24.202482Z

https://github.com/juxt/edge/blob/master/dev/user.clj#L18-L28 โ† example of this

dominicm 2017-06-05T15:00:58.216528Z

although I might be inclined to update the example to have better boundaries. But that's another matter ๐Ÿ™‚

2017-06-05T15:01:01.217550Z

cheers, might have to rethink our workflow

dominicm 2017-06-05T15:02:30.253299Z

:thinking_face: As long as you have a function which produces a system & takes a profile, you're golden. In your -main function, you use the (get-profile) function, this is what will be called in the uberjar. In dev, you have the dev/ directory on the classpath. And when you have your start stop reset going on in there, that takes care of enforcing the :dev profile. Let me know if you need any help ๐Ÿ™‚

๐Ÿ‘ 1
2017-06-05T15:49:04.316416Z

actually making changes to an existing app atm but will ask if I have any relevant questions

dominicm 2017-06-05T15:52:29.395712Z

okay