A question about cprop, I am reading: https://github.com/tolitius/cprop#merging-configurations

and I gather that the :merge clause is merged after

am I correct in saying that this part is therefore not overridable by system props/env vars?

ok no

it is not correct lol

it is not overridable by conf and classpath resource file

if I understand correctly what the question is 🙂 you can set the order in :merge

no I had a bug yesterday but it is more a bug in my head 😄

you can do crazy things like:

(load-config :resource "path/within/classpath/to.edn"
             :file "/path/to/some.edn"
             :merge [{:datomic {:url "foo.bar"}} 
                     (from-file "/path/to/another.edn")
                     (from-resource "path/within/classpath/to-another.edn")
                     (parse-runtime-args ...)
                     (from-system-props)
                     (from-env)])

so I have a conf file

but in most cases you don't have to

then I do:

(c/load-config :merge [env/defaults
                         {:version (if-let [version (version!)] version "0.0.0")}])

ok, conf is an edn file?

yes

so I expected that my conf file could override the stuff in env/defaults

env/defaults returns you a map with overriding paths?

yeah

every prop matches

but conf takes precedence on the :merge clause right?

hm.. not really, here is the order:

1. classpath resource config
2. file on a file system (pointed by a conf system property or by (load-config :file <path>))
3. custom configurations, maps from various sources, etc.
4. System properties
5. ENV variables

yeah 😄

that's why I was saying...read the docs Andrea!

that's ok, I don't expect people to read it, it just there for my reference to answer questions quickly 🙂

the README is consistent

lol

good point

if you still want to override the defaults, you can add a element to the :merge map

the way I usually do it is to have a file in a classpath, say config.edn

yeah now it is super clear

I will do this:

(defn make-config
  "Creates a default configuration map"
  []
  (merge env/defaults
         (c/load-config :merge [{:version (if-let [version (version!)] version "0.0.0")}])))

then I would have a (say) dev overrides somewhere under dev-resources/dev-overrides.edn, and then I start things with -Dconf=dev-resources/dev-overrides.edn

then I can just do (load-config)

but there are many ways to do it of course

yes, the thing is, I already have that

I wanted an external file

per-server

and conf it is very convenient

where would the file live?

on the server

somewhere on that server

right, so you can just have config.edn in your classpath (which would be read by default), and just use -Dconf=server-path-to/overrides.edn

yep, the env/defaults thing is a namespace a-la-Luminus for codeful conf

so it makes sense to merge it first (no priority)

I usually have things that I always want to override as:

:server {:application {:version "OVERRIDE ME"}
        :http {:port "OVERRIDE ME"
               :max-channel-memory-size 0
               :max-total-memory-size 0
               :http {:request {:max-chunk-size 8192
   ...

yeah I keep those there but empty

and then

:server {:application {:version "1.0"}
          :http {:port "4242"}}

great yes I am doing the same

or via ENV

the file is convenient because I can just copy the one in resources

SERVER__APPLICATION__VERSION=1.0

and launch java with -Dconf=....

right, whatever works 🙂

ah ah, the important is to have the choice and cprop gives you plenty

yea, I am actually experimenting with Vault ( https://github.com/tolitius/gblog ), and going through my thinking phase on having a cprop extension to it

since ENV and plain files are not really that good for secrets

oh that's a wonderful tool did not know it (I mean Ghost)!

yeah encrypted stuff would be great to integrate in cprop, but at least one piece of info has to be clear text on the server I guess

not really 🙂

it could be a temp token, that would only work for you and only one time and only for the next 5 seconds

to fetch creds to the runtime

i.e. you would run things like:

export ACCESS_TOKEN=$(./tools/vault/wrap-token.sh /secret/postgres); docker-compose up

cool stuff

where Vault would wrap the location into a token, which you can set a ttl on

it would only work for /secret/postgres, and only once

and encrypting of the info is done with a master key before that (sorry dunno how vault works)

I guess is basically some sort of bitcoin seeded wallet

right, when you install Vault you get a root token. you don't have to give it out to others, but you can use it to store secrets in Vault. you also can create a token for someone else to store creds to Vault (no need to use the root token). once creds are set / stored, all the apps that need these creds would only need a temp token

nice

yea, pretty cool

it is kind of similar to bitcoin really, as long as you don't lose your master key, you can always generate tokens/public keys to decrypt

I'll have a look

thanks for sharing!

sure, always welcome