-
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
cprop cannot handle setting nils #35
Comments
- The previous regex checks are redundant given `edn/read-string` provides the same functionality.
the reason for str->value to front the Clojure reader is because not all configuration and properties come from edn like in your table above. Some of them, quite often, come from ENV, system properties or configuration managers (e.g. Consul). In those cases types are not as clear. For example, let's look at overriding a "username": => (require '[cprop.core :as cp])
=> (cp/load-config)
{:datomic ...
:source
{:account
{:rabbit
{...
:username "guest"}}} => (System/setProperty "source_account_rabbit_username" "0x42") with the way code is written now: => (cp/load-config)
{:datomic ...
:source
{:account
{:rabbit
{...
:username "0x42"}}} relying on Clojure reader (i.e. removing "these lines"): => (cp/load-config)
{:datomic ...
:source
{:account
{:rabbit
{...
:username 66}}} I added better comments and a test so it clarifies things a bit |
Thanks for the quick turn-around! Yeah there’s definitely some overlap where things can be parsed oddly; though I think the times where the reader would mis-parse something would be the vast minority situations. Anyway, my original intent was lost among my thoughts on the use of the reader: you cannot nil a setting, it’ll be set to “nil” instead. A simple |
So it turns out
cprop
cannot handlenil
ing a setting. After some looking around and some testing I think the problem is just one of unnecessary complexity:The
str->value
function tries to be smart and does some long/boolean/string regex matching before sending the value toedn/read-string
. This processing is both unnecessary and can actually limit functionality as mentioned in the title:I'm fairly certain simply removing the regex matching from
str->value
would only add functionality to the parsing. Anecdotally: before babashka supportedcprop
as a library, I mimic'd the behavior using justedn/read-string
and it worked like a charm.The text was updated successfully, but these errors were encountered: