:assoc-fn is called with the value of the current option-map, which is assumed to contain the default value of the option. This patch changes :no-defaults to call select-keys on the option map before returning to the user.
While attempting to compile options from multiple sources, I discovered that it was difficult to extract only the subset of options actually specified in a given input line. With :no-defaults and get-default-options, constructing an option map is much more flexible than before.
Users should be able to extract the default map from their own option vectors without calling parse-opts with an empty args vector.
As opposed to compiled option specification maps.
Multiple options for the same :id makes some sense: [["-v" "--verbosity" :default 3 :parse-fn #(Integer/parseInt %)] ["-q" "--quiet" :id :verbosity :parse-fn (constantly 0)]] However, multiple :default entries for the same :id does not make sense, so it is prohibited. The identity constraint on :id remains.
Jean Niklas L'orange, in TCLI-9: > In many cases, I have input arguments where I want to perform multiple > validations, and return different error messages based upon that. > Would it be reasonable to have multiple validation functions, or being > able to have a validation function returning nil if no errors exists, > and an error string if not? This is an implemenation of the first suggestion, multiple validation functions. The :validation entry can now have multiple entries, which are partitioned into pairs, then split into the vector entries :validation-fn and :validation-msg. It would be nice to have a pluralized key name here, but we decline this for backwards compatibility. Non-collection values of :validate-fn and :validate-msg continue to be supported by conditional wrapping. Example: [["-f" "--file PATH" :parse-fn io/file :validate [#(.exists %) "File does not exist" #(.isFile %) "Path is not a regular file" #(.canRead %) "File is unreadable"]]] Addresses TCLI-9.
I have noticed some confusion about the new API. For instance, users are using the old :flag entry from cli/cli to try to denote that an option is a boolean flag. Hopefully, a friendly warning during compile time will encourage a closer look at the documentation.
A stylistic change to avoid :use in the ns declaration.