Fork me on GitHub
#duct
<
2020-06-26
>
plins21:06:58

hey everyone, Im trying to to make duct read configuration from env vars (this part is ok!) but im trying to find a way, in development and in test, to export specific env variables is dev/resources/dev.edn the right place to do so? (I intend to commit these default values) Im aware that I can use default values like

{:port #env ["PORT" Int :or 3000]}
but Id like to avoid default values production so Ideally the application always reads from env, and when Im developing or run lein test other env variables are used

walterl21:06:35

You can override the keys in your dev/test profiles. So in your base profile (which will filter through to prod) you can have {:port #duct/env ["PORT" Int]}, and in dev/test {:port #duct/env ["DEV_PORT" Int :or 3000]}.

plins21:06:31

so I have to duplicate the edn file structure in the test profile? but change only the :port field?

plins21:06:57

sorry for the noob question but where is my dev/test profile?

plins21:06:05

I need to create one for test?

walterl21:06:13

I'd recommend creating a sandbox project with lein new duct sandbox to have a "live" example you can play with

walterl21:06:35

The default config looks like this:

{:duct.profile/base
 {:duct.core/project-ns sandbox}

 :duct.profile/dev   #duct/include "dev"
 :duct.profile/local #duct/include "local"
 :duct.profile/prod  {}

 :duct.module/logging {}}

plins21:06:02

done 🙂

walterl21:06:10

With an empty dev config in dev/resources/dev.edn

walterl21:06:05

> so I have to duplicate the edn file structure in the test profile? No, integrant is smart enough that you can only override the keys you want to change

walterl21:06:15

So if you have {:some/component {:foo 1, :bar 2}} in your base profile, and {:some/component {:foo 10}} in your dev profile, the component will end up getting initialized with {:foo 10, :bar 2}

plins21:06:31

this is cool 🙂

Kevin08:06:33

FYI, this is used by duct for merging configuration: https://github.com/weavejester/meta-merge You can see all the options you have with this

👍 3
plins21:06:43

thank you so much for you detailed explanation

plins22:06:10

so -main is not executed when we use the repl? when its executed?

plins22:06:02

lein run runs it with the production profile unless we specify otherwise then?

walterl22:06:21

lein run will always run the production profile, given the default main.clj

walterl22:06:46

Note the profiles [:duct.profile/prod] on main.clj's line 9

plins22:06:34

how can I specify other profile? lein with-profile :duct.profile/my-profile run is not working

walterl22:06:29

lein profiles != duct profiles

plins22:06:35

hmm I see

walterl22:06:46

You'll need to update that profiles vector in main.clj

walterl22:06:59

... if you want to run a different profile from lein run

walterl22:06:07

For dev, that's usually not necessary

plins22:06:45

you are right

walterl22:06:54

You should rather lein repl, and then (dev) and (go)

👍 3
plins22:06:06

and when running tests

walterl22:06:24

See dev/src/dev.clj and dev/src/user.clj to see what that does 🙂

plins22:06:34

lein test should load the test profile, right?

plins22:06:05

it happens out of the box or some configuration is needed?

plins22:06:55

looks like lein test is using the prod profile

walterl22:06:55

Tbh, I'm not sure

plins22:06:10

well Ill try to find out thanks once again 🙂

walterl22:06:18

Ah, I see now. We added a test fixture that inits the duct system, and it takes a profile arg to specify the profile to use (we have :test and :test-e2e profiles). Each test uses that fixture then: (use-fixtures :each (hh/system-fixture :test))

plins22:06:34

Ill try that thanks 🙂