Fork me on GitHub

That sounds hard.

Alex Miller (Clojure team)02:08:39

the hard part is that you don’t know how many params f takes

Alex Miller (Clojure team)02:08:42

I don’t know that it’s profitable to spec such a thing at that level


is there a way to take a map schema of un-namespaced keys, and promote them to namespace qualified ones? -- I'm imagining something like:

(s/def ::id int?)
(s/def ::config (s/keys :req-un [::id]))
(s/some-conform-like-function ::config {:id 10})
;; -> {::id 10}

Alex Miller (Clojure team)08:08:52

this is kind of an aside and I assume you did this really for readability, but you’ll never see ::id printed - autoresolved kws are only read, never printed but you could certainly use a conformer to do this

Alex Miller (Clojure team)08:08:59

(defn qualify-keys [m]
  (zipmap (map #(keyword (str *ns*) (name %)) (keys m)) (vals m)))

(s/conform (s/and ::config (s/conformer qualify-keys)) {:id 10})
;;=> #:user{:id 10}


This has probably already been asked, but can I somehow pprint the error messages thrown by (spec.test/instument)? They are pretty much impossible to read for what I’m doing right now.


Hi, seems I missed a few updates and instrument-all is not in clojure.spec anymore. What is the idiomatic approach to enable the specs during tests with the latest alpha release?

Alex Miller (Clojure team)19:08:55



@alexmiller Ah, there it is and without arguments it instruments the ns, right?

Alex Miller (Clojure team)19:08:24

it instruments everything in the registry

Alex Miller (Clojure team)19:08:38

when you pass it no args


Even better, thank you very much

Alex Miller (Clojure team)19:08:53

same thing for unstrument and check


(cross-posted from clojurescript...but no answer there): do others find it difficult to spec functions that use core-async for backend comms? This seems where stubbing would be very helpful, that is to stub out backend service calls. However since core-async based functions only return channels, not request do other people tackle this issue?


@fenton there’s no story for that yet


ok, i'll nut it over with some clojure devs here at our Vancouver, Canada, meetup...see what we come up with.


maybe this came up before, but wondering if this is being thought about. There is some overlap in clojure.spec'ing and datomic schema spec'ing. Could these be unified?

Alex Miller (Clojure team)21:08:45

eventually I expect that spec will be more intimately involved in both core.async and Datomic

Alex Miller (Clojure team)21:08:01

but that’s a ways off


@alexmiller cool. glad to hear that is the direction tho! 🙂


Is there a better way to do the following? I'm figuring the registry-ref is private for a reason, but I couldn't come up with another way to temporarily override the value of a spec. My usecase is that during runtime, it is okay for a spec to be nilable, but not during test time. Looking for any suggestions for this. I did try writing the specs separately, but that ended up with (quite a bit) of duplication since the spec I need to redef is nested a few levels down.

(defmacro with-spec-redefs
  [& forms]
  `(let [previous-registry# (s/registry)]
     (let [result# (do [email protected])]
       (swap! @#'s/registry-ref (constantly previous-registry#))

(s/def :my/awesome-string #(re-seq #"123" (str % "3")))

  (s/def :my/awesome-string (s/nilable #(re-seq #"123" (str % "3"))))
  [s/valid? :my/awesome-string nil
   s/valid? :my/awesome-string "12"])