Replies: 3 comments 9 replies
-
|
@lread I have a first draft here that's ready to merge. Can you review this? |
Beta Was this translation helpful? Give feedback.
-
|
I am playing with the expose branch and noticed a tiny difference from main branch. (let [errors (atom [])]
(cli/parse-args ["--foo"] {:spec {:foo {:coerce [:keyword]}}
:error-fn #(swap! errors conj %)})
@errors)
;; main branch
;; => [{:spec {:foo {:coerce [:keyword]}},
;; :type :org.babashka/cli,
;; :cause :coerce,
;; :msg "Coerce failure: cannot transform (implicit) true to keyword",
;; :option :foo,
;; :value "true",
;; :opts {}}]
;; expose branch
;; => [{:spec {:foo {:coerce [:keyword]}},
;; :type :org.babashka/cli,
;; :cause :coerce,
;; :msg "Coerce failure: cannot transform (implicit) true to keyword",
;; :option :foo,
;; :value ["true"],
;; :opts {}}]Notice the difference in the |
Beta Was this translation helpful? Give feedback.
-
|
I'm thinking about edn file value coercion. It is appropriate to be as forgiving and kind when coercing from edn file values as we are when coercing from command line args to opts? An edn file allows exact specification of typed values. (cli/coerce-opts {:foo "blarp"} ;; this is not in a vector
{:spec {:foo {:coerce [:keyword]}}})
;; => {:foo [:blarp]}I suppose there is no one right answer. That said, I've experimented with coercing edn file values in my old squint PR (against your bb cli expose branch): lread/squint@0eef0f3 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Use Case
Babashka cli seems to assume that input is only coming from the command line.
This seems reasonable, given, well, its name is
cli!But, input can also come from, for example:
.ednfileIn these cases, the values have been parsed by other means, but I still want to coerce and validate them. And likely, in the case of an
.ednfile (and maybe properties and env vars), I might want to validate after merging with parsed and coerced cli values before dispatch. I cannot do this today because behaviour is coupled (and sometimes intertwined).A Look at Current Behaviour
If I've understood:
parse-optsargsand coerces values at same timedispatchargs(effectively viaparse-opts)A Rough Draft of Decoupled fns
I'm wondering if we could tease out (without breaking any existing API) something like:
parse-cli-args(converts cli args to map of option/raw-value(s))coerce-opts(converts option/raw-value(s) to option/coerced-value)validate-opts(restrict, require, other validation)dispatch-lookup(looks up dispatch cmd)dispatch-invoke(invokes dispatch fn)dipatch-?(I have to think more about dispatch decoupling)There might be 2 types of coercion. One type of coercion accommodates the limitation of the command line.
:collectcomes to mind, and also coercing multiple values to a vector. Another type of coercion might be thought more of as user-kindnesses, like coercing a string to a keyword, for example. It might be useful to separate the first from the 2nd, not sure yet.Is this worth digging deeper?
This would not be a tiny effort, so before I dig any deeper, do you also find the idea interesting?
Beta Was this translation helpful? Give feedback.
All reactions