Troubles with spec's coercion

[WhittlesJr]

I'm really liking this library, but I ran into a minor roadblock.

Consider an s/or spec being given for the :spec of a cfg/def. Assuming the configured value is valid for the spec, the "coerced" value becomes a vector with the s/or key first and the actual value second:

(s/def ::transport #{:ip :serial})
(s/def ::transport-cfg (s/or :enabled  ::transport
                             :disabled #{:disabled}))

(cfg/def MODBUS_TRANSPORT
  {:doc      "Transport layer to use for Modbus."
   :spec     (cfgc/from-edn ::transport-cfg)})

(::transport comes from a different namespace IRL, hence the separation.)

In this case, if MODBUS_TRANSPORT is set to ":ip", the coerced value becomes [:enabled :ip].

Other than creating a second var like below, I can't think of any good way around this:

(def modbus-transport (some-> MODBUS_TRANSPORT second))

This doesn't strike me as a very clean solution. Ideally, I'd want to be able to specify a coercion function separately from the :spec, and have that function alone run against the raw value. Then the spec would be only used for validation, and our values would not be polluted by spec's rather odd habit of sometimes conforming values to non-valid outputs (as in this case.)

[WhittlesJr]

I've been trying some other possible solutions but I can't seem to get it right. I'll keep poking at it a bit though.

[WhittlesJr]

I think the answer lies in using https://github.com/wilkerlucio/spec-coerce. Hopefully there will be a PR today.

Unfortunately this would be a non-trivial change, and the interface would effectively change as well. I'll put together the PR and we can evaluate its relative merits.