Clojurians Log v2

Would using :replace instead of :stub work in this case?

Hey folks, Looking for a bit of advice about adding specs to an open source project. We have a "command syntax" where commands are basically vectors. A few examples are provided below but essentially each command's first item is an op-code and subsequent items configure the operation in an op-specific way....

[:do some-side-effect-fn]
[:write! :foo {:id 1 :payload "yolo"} optional-args]
[:watch some-pred optional-args]

Ah I've just seen how crux does it. https://github.com/juxt/crux/blob/b7fdb38357adb85627c3be5710d0aff26a796f19/crux-core/src/crux/tx/event.clj I think our commands follow the same sort of pattern as their transactions so can probably just use that. I didn't realize that multi-spec could be used with non-map shaped structures.

If you look in the spec 2 repo currently there is still the keys spec, will that stay? If so, with schemas/select is there a suggested limited set of usecases for keys now?

@colinkahn I have seen a couple of mentions from @alexmiller indicating that keys may not stay in the final Spec 2 version -- but Spec 2 is still very much alpha and in flux. Also the fdef stuff is likely getting a substantial overhaul.

I spent quite a bit of time tracking Spec 2 last year and had a branch of our system at work that passed all tests using Spec 2 instead of Spec 1 -- but still using keys and there were quite a lot of changes just to get to that point (and a number of bugs and workarounds I had to deal with). I gave up in early October and decided that we wouldn't attempt a direct migration from Spec 1 to Spec 2: instead we'll adopt Spec 2 for new code and perhaps incrementally replace our Spec 1 usage over time.

One thing that needs to be figured out for a mixed Spec 1/2 codebase is how the spec systems interact, because Clojure itself uses Spec 1 (1.9, 1.10) and so you can't (easily) mix core specs with your own Spec 2 stuff right now.

Thanks for the insight @seancorfield. In your experience do you think your refactor would have been easier if you were already using https://github.com/ComputeSoftware/spec1-select for you spec 1 code? I’m looking to port some of my code over to it. Regarding keys I was curious if the (and) and (or) syntax used within :req/opt(-un) would exist in some form in spec 2.

Our use of Spec dates back to early alphas of Clojure 1.9 so that library is moot for us.

Right, not saying for your specific case but I’m evaluating using it to make our transition to spec 2 eventually smoother

Given how much Spec 2 is in flux, I don't know that such a library would necessarily be a useful starting point. Most of the work for us in attempting to get our Spec 1 codebase running on Spec 2 was around the much stricter delineation of symbolic specs vs spec objects etc.

We had a lot of Spec 1 specs that simply weren't legal in Spec 2 and we had to rewrite them to use defop and various other constructs.

Remember: we stayed with keys when we attempted that migration -- it wasn't about switching to schema/`select`... that was considered "future work".

Good to know, I haven’t dived into the defop stuff in spec 2 yet so didn’t consider that. Besides future compatability I definitely feel the pain points that schema/select are meant to solve, which is why I’m seeing that as a valuable first step.

Re and/or - no, probably not

Schemas support unqualified keys in spec 2

Sure, they are a big improvement on Spec 1's keys -- but I would be wary of relying on a 3rd party lib that tries to backport Spec 2 features onto Spec 1 when a) Spec 2 is still changing so much and b) Spec 2 already has stricter rules about "what is a spec" than Spec 1.

I don't consider a lib like that to be a useful "future proofing" option...

(it's an interesting exercise, to be sure, and if folks want some of what Spec 2 offers while staying on Spec 1 for an unspecified future time period then maybe it's of some use -- but I really doubt it will make the "migration" from Spec 1 to Spec 2 any easier)