cprop cannot handle setting nils

[bn-darindouglass-zz]

So it turns out cprop cannot handle niling 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 to edn/read-string. This processing is both unnecessary and can actually limit functionality as mentioned in the title:

cprop.source> (let [or-nil #(or % "nil")]
                (doseq [v ["hello" -1 100 100000000000000000000 -100000000000000000000 nil true false]
                        :let [cprop (str->value (str v) {})
                              edn (edn/read-string (str v))]]
                  (clojure.pprint/print-table [:parser :value :type]
                                              [{:parser "" :value (or-nil (str v)) :type (or-nil (type v))}
                                               {:parser "cprop" :value (or-nil cprop) :type (or-nil (type cprop))}
                                               {:parser "edn" :value (or-nil edn) :type (or-nil (type edn))}])))

| :parser | :value |                     :type |
|---------+--------+---------------------------|
|         |  hello |    class java.lang.String |
|   cprop |  hello |    class java.lang.String |
|     edn |  hello | class clojure.lang.Symbol |

| :parser | :value |                :type |
|---------+--------+----------------------|
|         |     -1 | class java.lang.Long |
|   cprop |     -1 | class java.lang.Long |
|     edn |     -1 | class java.lang.Long |

| :parser | :value |                :type |
|---------+--------+----------------------|
|         |    100 | class java.lang.Long |
|   cprop |    100 | class java.lang.Long |
|     edn |    100 | class java.lang.Long |

| :parser |                :value |                     :type |
|---------+-----------------------+---------------------------|
|         | 100000000000000000000 | class clojure.lang.BigInt |
|   cprop | 100000000000000000000 | class clojure.lang.BigInt |
|     edn | 100000000000000000000 | class clojure.lang.BigInt |

| :parser |                 :value |                     :type |
|---------+------------------------+---------------------------|
|         | -100000000000000000000 | class clojure.lang.BigInt |
|   cprop | -100000000000000000000 | class clojure.lang.BigInt |
|     edn | -100000000000000000000 | class clojure.lang.BigInt |

| :parser | :value |                  :type |
|---------+--------+------------------------|
|         |    nil |                    nil |
|   cprop |        | class java.lang.String |
|     edn |    nil |                    nil |

| :parser | :value |                   :type |
|---------+--------+-------------------------|
|         |   true | class java.lang.Boolean |
|   cprop |   true | class java.lang.Boolean |
|     edn |   true | class java.lang.Boolean |

| :parser | :value |                   :type |
|---------+--------+-------------------------|
|         |  false | class java.lang.Boolean |
|   cprop |    nil | class java.lang.Boolean |
|     edn |    nil | class java.lang.Boolean |
nil

I'm fairly certain simply removing the regex matching from str->value would only add functionality to the parsing. Anecdotally: before babashka supported cprop as a library, I mimic'd the behavior using just edn/read-string and it worked like a charm.

[tolitius]

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

[bn-darindouglass-zz]

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 (= “nil” v) before the alpha number regex should fix the use case.