-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
better match the behavior of assoc-in
#33
Comments
assoc-in
vectorsassoc-in
the problem with the first regex solution is that the key name might become ambiguous: i.e. 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 |
Yeah the ambiguity is definitely a problem with the first suggestion; however I'd almost argue using any 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. |
This allows for custom parsing of each part of a key's path. One example of a use-case is to better match the behavior of `assoc-in` (i.e \d+ being treated as indices rather than keywords) - Add new parse-fn to source.cljc - Add new tests around this option - Use `testing` instead of comments before `is` forms
- Update key-part parser option name - Move number parsing function into tools namespace - Update README with direct example
- It was private before so it shouldn't be a breaking change.
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
usesassoc-in
to make these updates which can support indices if the current root level is a non-map:I propose one of two options:
#"^\d+$"
then it should be treated as along
instead of akeyword
to better align withassoc-in
's behavior.k->path
function so users can parse paths in ways they would expect.The text was updated successfully, but these errors were encountered: