tools.cli: 验证默认值？

Question

下面是在我的工作中经常出现的一种模式

(def cli
  [["-f" "--foo FOO"
    :default-fn (fn [_] (System/getenv "FOO"))
    :default-desc "$FOO"
    :validate [seq "You must either use --foo or set $FOO"]])

不幸的是，它并没有按预期工作。即使有 :post-validation true，默认值也不会由验证器验证。相反，我必须编写一个单独的手动验证函数。我怀疑这是因为验证器不会运行，除非该选项被调用。

有 :post-validation 使得验证器在具有默认值的选项上运行是否合理？或者也许一个额外的选项是有意义的，比如 :validate-default？

Answer 1

由于你控制默认值，所以存在一个固有的假设，即你应该自己检查它——因为无效的默认值是编程错误，而不是使用错误。

它还充当一个逃生门，这样您就可以提供用户通过选项无法提供的自定义默认值，这在某些情况下是必需的。

Comments

当然可以，我认为这是一个合理的默认值，但为何不给开发者提供一个选项，让他们可以选择是否验证默认值？将选项回退到某种外部值（如环境变量、配置文件等）是一个非常常见的模式，而 tools.cli 可能会更好地支持这种模式，这也会是一个实现这一点的简单方法。

---

---

---

  [["-U" "--gitlab-uri URI" "Gitlab host URI" :parse-fn #(URI. %)]
   ["-t" "--gitlab-token TOKEN" "Gitlab token"
    :default ::absent
    :validate [(fn [x] (println "XXXXX:" x) (not= ::absent)) "Missing required option: --gitlab-token"]
    ]
   ["-h" "--help"]])

不见得有效，因为：:validate fn 从未被触发。我实际上更喜欢某种类型的：:mandatory（:required 早就被占用了）属性来强制用户设置此选项。

---

在 tools.cli 中，“required” 表示选项后面需要跟随一个值，而不是选项本身是必需的。

我看到了几个增强的请求，都属于后处理类别，例如处理非选项参数、处理强制选项检查等。这目前是 tools.cli 没有任何“挂钩”的地方，但它似乎是一个很好的增强区域，所以我计划考虑一下。

感谢您对此的输入。