better match the behavior of `assoc-in`

[bn-darindouglass-zz]

Currently cprop assumes that all parts of a key path are keywords. Because of this assumption, only nested maps may be overridden by ENV vars, System properties, et al.

However, cprop uses assoc-in to make these updates which can support indices if the current root level is a non-map:

user=> (def servers {:redis [{:url "hi"}]
  #_=>               :es [{:url "world"}
  #_=>                    {:url "!"}]})
#'user/servers
user=> (assoc-in servers [:redis 0 :url] "hello")
{:redis [{:url "hello"}], :es [{:url "world"} {:url "!"}]}

I propose one of two options:

1. If a part of a path matches #"^\d+$" then it should be treated as a long instead of a keyword to better align with assoc-in's behavior.
2. Provide a way to inject a parsing function into the k->path function so users can parse paths in ways they would expect.

[tolitius]

the problem with the first regex solution is that the key name might become ambiguous: i.e. "0" vs. 0 vs. :0, etc.

you can substitute redis url in your example above using a nested map:

=> (c/load-config)
{:redis [{:host "localhost"}
         {:host "openstack"}]}

=> (c/load-config :override-with {:redis {0 {:host "prod"}}})
{:redis [{:host "prod"}
         {:host "openstack"}]}

let me know if it works for you

[bn-darindouglass-zz]

Yeah the ambiguity is definitely a problem with the first suggestion; however I'd almost argue using any ^\d+$ key in a nested map is poor convention.

As for your example, my suggestion primarily comes from values set at the environment level. We have nested config that (unfortunately) has some required order about it, hence the vector inside the config structure. As it stands now the only way to override any value inside that vector is to override the whole key containing the vector, which can get unwieldy.

We could do as you suggested but that would mean having to have a sort of "meta" config that'll read from the environment and get merged into the "real" config at load time. I'd imaging that'd get pretty confusing.