why env has a higher priority than command line arguments?

[pinkfrog9]

For example here:
https://github.com/tolitius/cprop#merging-with-all-system-and-env

             :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-props-file "/path/to/some.properties")
                     (from-system-props)
                     (from-env)])```

How to make cli have the highest precedence?

[tolitius]

usually ENV is the last step for overrides since apps, after already internally configured, are deployed in different environments.

only those ENV variables that match will end up overriding the final config, all other variables won't be used by default unless you force them to be used by :merge [(from-env)]

in most cases (load-config) is enough. In cases when it is not, add only what you need. For example if you need (parse-runtime-args ...) add just that:

(load-config :merge [(parse-runtime-args ...)])

In case you have no control over the ENV, but still want to override them as the last step, you can always do:

export DB__URL=foo; ./run-your-program

when you run your built, deployed artifact in the particular environment.

[pinkfrog9]

usually ENV is the last step for overrides since apps, after already internally configured, are deployed in different environments.

I cannot agree on this; command line args should always have the highest precedence, as in most softwares, for example: https://docs.aws.amazon.com/cli/latest/topic/config-vars.html#precedence

Nevertheless, thanks for the trick env FOO=BAR ./prog.

[tolitius]

aws example is first and foremost has to do with cli, hence command line arguments take precedence.

while thinking about it some more, I still believe there should be an existing merge order with ENV being the last layer, but I do agree that there has to be a way to override any layers with "that last" custom map.

I added an :override-with option that allows to do that.

This is in [cprop "0.1.15-SNAPSHOT"]. Thanks for bringing this up, and let me know whether it works for you.

[pinkfrog9]

yup. thanks for your quick response.

https://github.com/luminus-framework/guestbook/blob/master/src/clj/guestbook/core.clj#L22
another example in which the code explicitly uses cli args if existing and then revert back to other mechanisms.

[tolitius]

yep, I do agree having an option to override defaults is a good idea.

Let me know whether :override-with works for your use case (it is in [cprop "0.1.15-SNAPSHOT"]), I'll merge it into the release and close this.

[pinkfrog9]

override-with is fine.