load-config doesn't work with only :merge (or no key)

[tolitius]

load-config doesn't work with only :merge (or no key)

[tolitius]

It would all depend on how you choose to work with env overrides, but there are options. The simplest way: you can have you config.edn living in the classpath / file system. You would start your application with something like -Dconf=... and export ENV variables to override env specific properties.

Besides exporting ENV variables manually / with a script, you can use something like Consul or etcd or Zookeeper to read those values.

Both solutions above would resolve in just:

(load-config)

since cprop merges ENV variables by default.

Using a specific conf.env file for a specific environment is also of course an option. It can live in classpath / file system or could also live in consul/etc/zookeeper where, depending on env would be pushed to the app (or its docker image). In which case the you would just do:

(load-config :merge [(from-file "conf.env")])

or from-resource, depending where this file is being placed.

[tolitius]

from the docs:

---

By default cprop would look in two places for configuration files:

• classpath: for the config.edn resource
• file system: for a path identified by the conf system property

If both are there, they will be merged. A file system source would override matching properties from a classpath source,
and the result will be merged with System properties
and then merged with ENV variables
for all the matching properties.

check out cprop test to see (load-config) in action.

---

so the idea is that if relies on the configuration file (i.e. config.edn, or another, non default name) to be "there". All the merges happen to this file.

For example this would work:

$ lein try cprop

user=> (use 'cprop.core)
user=> (spit "i-need-to-exist.edn" "{:a 42}")
user=> (load-config :file "i-need-to-exist.edn")
{:a 42}

Are you looking for a different behavior?

[lerouxrgd]

Ok I see, when I read it the first time I didn't think that at least one of :file or config.edn on classpath was mandatory.
I think that as a default behavior explicit (empty map) is better than implicit (expecting a file called config.edn somewhere on the classpath).
But it is a matter of taste that is up to you desinging the lib, so don't hesitate to close the issue, thanks.

[tolitius]

Currently, in case it does not find a resource or a file cprop would complain. This complaint is quite welcome beyond development, since it communicates the fact that the file that was given via ENV or -D or a classpath was not found: i.e. it is clear, and does not start an application without its configuration.

But you could be right.. to allow load-config to just take a map and then run all the merges on that map might be useful in development / testing. When would you use it and how?

[lerouxrgd]

I am using cprop for configuring a system (from component library).
All the config files are under a config directory and I intended to load them as follows:

(defn merge-configs [conf-from-app]
  (let [conf-from-sys (from-system-props)
        conf-from-env (from-env)
        env (name (or (:env conf-from-app) 
                      (:env conf-from-sys) 
                      (:env conf-from-env)
                      (throw (IllegalArgumentException. ":env is missing"))))]
    (load-config :merge [(from-file "config/defaults.edn")
                         conf-from-app
                         (from-file (str "config/" env ".edn"))
                         conf-from-sys
                         conf-from-env])))

That's how I got an error.
Now I moved out "config/defaults.edn" into a :file parameter.