I want to include malli.experimental.time but can't seem to register the schemas. Details in 🧵
I've added this to my core namespace
(malli.registry/set-default-registry!
(malli.registry/composite-registry
(m/default-schemas)
(met/schemas)))But then starting the app fails with
; Execution error (ExceptionInfo) at malli.core/-exception (core.cljc:157).
; :malli.core/register-function-schemaI can however run this code from the REPL after the app has started and then the time schemas are registered
Any idea what is going on? Where should one place set-default-registry!
Update - registering the schema does not seem to be the problem!
It's when I use the :time/zoned-date-time in a top-level instrumentation of a function that I get the exception. Is the instrumentation running before the core namespace registers the time schemas?
I can run the instrumentation after the app has started and then everything works
Oh, nvm, the namespace that instruments the function needs to depend on the namespace that registers the time schemas.
How do people solve this generally? Seems easy to forget to require the namespace that does the registration everywhere where you instrument functions?
Even more generally if I need to ensure a top-level side effect has happened before evaluating something I use vars + linting. For example, here I would create a new namespace that sets the default registry, and expose tiny wrapper macros for all the operations I'd like to only happen after it has loaded. Then I use a linter to ban uses of the "raw" macros in my project.
;; my_app/malli.cljc
(ns my-app.malli
(:require [malli.core :as m]))
(malli.registry/set-default-registry!
(malli.registry/composite-registry
(m/default-schemas)
(met/schemas)))
;; now add a clj-kondo rule to ban malli.core/=> in my project
#?(:clj (defmacro => [& args] `(m/=> ~@args)))Makes perfect sense, thanks!
I just wanted to say thanks for making Malli! I had always avoided it before as “too fancy for me”, but it’s really working well for one of my current use cases. Particularly, I found myself needing to dynamically define schemae at runtime and generally treat them as a datatype of their own that can be operated upon.