Clojurians Log v2
expound
first time using expound! Looks extremely useful, although, using the example from the readme as is in my repl produces an error -
(s/def :example.place/city string?)
(s/def :example.place/state string?)
(s/def :example/place (s/keys :req-un [:example.place/city :example.place/state]))
(expound/expound :example/place {:city "Denver", :state :CO})
=> :example.place/city
=> :example.place/state
=> :example/place
ExceptionInfo Unknown data:
clojure.core/ex-info (core.clj:4725)
what am i missing?
@aymat316 Hm, I’m not sure. How are you requiring expound?
I tend to use lein repl, so if you’re using another REPL, let me know and I’ll try it. Also, what version of Expound and clojure.spec are you using?
@bbrinck I use nREPL -
nREPL server started on port 55098 on host 127.0.0.1 - <nrepl://127.0.0.1:55098>
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0-alpha16
Java HotSpot(TM) 64-Bit Server VM 1.8.0_102-b14
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
[org.clojure/clojure "1.9.0-alpha16"]
[expound "0.7.1"]
Hm, I’d be surprised if it matters, but can you try Clojure 1.9.0 (without the alpha)? I haven’t done regression testing against alphas
Did you start the REPL with lein repl or boot repl?
Ah, yes, I just tried with alpha16 it looks like 0.7.1 is incompatible with alpha16
I use lein repl .. gonna try with 1.9.0 .. not sure why I was using alpha
Did that help?
yes, that worked, thanks! Although, sadly, I may not have a choice at the moment and might have to stick with alpha16 since we use that across our stack.. will need an upgrade across the board
Ah, I see. I would expect that the upgrade to 1.9.0 should be relatively painless. I haven’t dug through the changelog, but I would imagine it would be mostly bug fixes with few breaking changes.
I was going to suggest an older version of Expound, but it looks like the first supported version is alpha17. Sorry!
ah damn ! lol .. well good reason for us to finally upgrade.. I hear we tried once but stuff broke on our service layer 🙁 , so we might have to upgrade slowly and carefully .. Thanks @bbrinck for the help!
Good luck!
looks like I can upgrade to 1.9.0 .. my follow up question, does expound have the ability to return custom error messages as data (similar to s/explain-data), rather than print them? I’m hoping to use the error messaging on the front end
@aymat316 It can return the formatted string, but no, it doesn’t currently have a simple way to return the data. I’m not sure that the explain-data returned by expound would be meaningfully different than the data returned by s/explain-data
Can you talk a little more about what you’d like to do with the data? And how expound/explain-data might differ from s/explain-data? Currently expound just adds a little bookkeeping data that it uses internally, but I’m not sure it’s more widely useful (but I could be wrong)
Of course, you could just get the string with expound/expound-str and return that to front-end, but I don’t know if that helps
actually I think a return of just the error string should work for me .. I don’t think I need something as elaborate as s/explain-data .. but I’ll need to parse the string. . just wanted to know if there was a function to return to me only the custom error string I’ve defined for the spec (without the --- Spec failed --- etc.)
Ah, no, not yet. You can control some parts of that string though
yes, I just saw the printer options.. will most likely use that along with some manual parsing
e.g. you can remove that “Relevant” specs section
cool
untested, but basically do this:
(binding [s/*explain-out* (expound/custom-printer {:print-specs? false})]
(s/explain-str my-spec my-value))
Hopefully in beta timeframe more things will be configurable, and I’ll consider returning the output as structured data instead of a single string
sounds good! thanks! cool stuff