That sounds hard.

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

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}

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

with conform

(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.

Not yet

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?

(clojure.spec.test/instrument)

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

it instruments everything in the registry

when you pass it no args

Even better, thank you very much

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 responses...how do other people tackle this issue?

@fenton there’s no story for that yet

@dnolen ok...

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?

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

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 ~@forms)]
       (swap! @#'s/registry-ref (constantly previous-registry#))
       result#)))

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

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