Skip to content
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

why env has a higher priority than command line arguments? #28

Open
introom opened this issue Jul 9, 2019 · 6 comments
Open

why env has a higher priority than command line arguments? #28

introom opened this issue Jul 9, 2019 · 6 comments

Comments

@introom
Copy link

introom commented Jul 9, 2019

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
Copy link
Owner

tolitius commented Jul 9, 2019

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.

@introom
Copy link
Author

introom commented Jul 9, 2019

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 added a commit that referenced this issue Jul 9, 2019
tolitius added a commit that referenced this issue Jul 9, 2019
@tolitius
Copy link
Owner

tolitius commented Jul 9, 2019

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.

@introom
Copy link
Author

introom commented Jul 10, 2019

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
Copy link
Owner

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.

@introom
Copy link
Author

introom commented Jul 10, 2019

override-with is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants