Fork me on GitHub

is there any roadmap for spec 2? we plan to add spec validations to our codebase and if spec 2 is reasonably close we'd go straight with that


roadmap in terms of things to do or timing


I guess you mean timing


I would not expect it to be "done" for at least another month or two

👍 1

we could work on adding it from this fall (october <) so that sounds promising to me


well, you might be fine then


you can use it right now as a git dep, but it is definitely a work in progress


@vale We have a branch of our code base running on Spec 2. There are definitely some interesting differences from Spec 1, and if you do anything where you need to share specs between 1 & 2 (perhaps because you use specs from a library that depends on Spec 1), you'll need to jump through some hoops.


I've landed two big sets of changes in the last week there, will have a writeup on some new stuff tomorrow

💯 3
👍 1

(just in time for me to go to England for a week so I won't get to play with it until I get back!)


i heard you mention that on the defn podcast, but i'm not adventurous enough to use it in production code


we're adding spec from zero, and that 1/2 difference thing is exactly the reason i'd prefer to go straight to 2 if it's feasible


on a similar note, any plan on making it not-alpha?


Just reviewing those commits @alexmiller -- love the new closed spec approach!


@vale Oh that branch isn't in production -- just dev -- until Alex green lights production use (even in alpha).


We started using Spec 1 in early alpha in production. We take most Clojure alpha builds to production. But Spec 2 isn't yet at that point.


Based on past experience, I'd expect Spec 2 to stay alpha for quite a while before it moves to a beta. tools.deps is still alpha and it's core to the CLI / deps.edn tooling.


yeah, we're still actively changing the api in spec 2 and I don't think that's done yet. we're not going to have a "release" until that settles down


my hope is that it can be stable enough to be non-alpha and so it will never release as spec-alpha2 at all, but will depend on timing


tools.deps edges ever closer to me being comfortable with taking it off alpha


the api is pretty stable there


@alexmiller Good to hear that about Spec 2. Targeting "release" by Conj?


Re: tools.deps -- any decision on add-lib yet?


oh nice! it could be tricky to explain to stakeholders how something labelled alpha is production ready


@vale Stakeholders outside the Clojure world, yes. But inside the Clojure world there's much more stability than almost any other language.


We went to production originally, back in 2011, on Clojure 1.3 Alpha 7 or 8, and we've run almost every single pre-release build of Clojure in production ever since.


Quite a few Contrib libs have been in pre-release mode for ages on various revisions and it's "expected" that folks will use them, reporting any problems, but on the assumption that they're "solid". There is, after all, a mindset -- driven from the top down -- of accretive/fixative change rather than breakage.


(that said, some libs have had breaking changes several times -- including that I have maintained for about eight years!)


upvote for add-lib in tools.deps please 🙂


@alexmiller Closed spec looks so much better now (also read the commits)! As the settings open up more options to do things, it would be great if you would time to re-check the proposed patch in, as it had similar approach, but I believe, would be even more generic way to do this, for even to apply coercion. Or if that’s an bad idea, that should be declined as it’s now partially overlapping with the new design.


Well, all spec patches in jira are probably long broken given that I’ve rewritten pretty big chunks of it multiple times


Once we get through the majority of new feature type stuff, I will go through them all but no point now


As I’ve said in the past, I think it’s highly unlikely that we’re going to take clj-2116 regardless


I don’t think it’s a good way anymore either (2116), wrote a the spec walker issue later that could be the one generic way to walk over specs + values, and could be used for both.


Well, we’re working on the walking stuff too

👍 1

currently spec-tools & spec-coerce walk the spec forms which is IMO not a right way to do that.


The other half of what I’m working on now is dataficatiom of specs


cool. just for browsing or also transforming?


Either - the input side is there now


Once you have the output side, then transformation is just normal clojure stuff


one common case for closed specs has been the “strip out extra keys” functionality, is that doable with the new closed feature? e.g. before saving to the database / when reading input from untrusted clients / intenet.


Haven’t really considered it. Why not just use select-keys?


select-keys for a deeply nested structure mean double-maintaining the keysets. some helper would be nice


I think we’re giving you a lot of new tools to build your own spec that does something like this (flag passed through settings) but we have not talked about any plans to add this


This again feels like a coercion/transformation use case which we don’t believe is a job for conform


ok. the data is there (keysets) already to feed a select-keys. would love to throw away stuff from spec-tools, when they are doable with spec itself. currently:

(s/def ::name string?)
(s/def ::street string?)
(s/def ::address (s/keys :req-un [::street]))
(s/def ::user (s/keys :req-un [::name ::address]))

(def inkeri
  {:name "Inkeri"
   :age 102
   :address {:street "Satamakatu"
             :city "Tampere"}})

(st/select-spec ::user inkeri)
; {:name "Inkeri"
;  :address {:street "Satamakatu"}}


spec-tools does that nowadays with form walking btw.


I think that would use the upcoming “walker”, so a good test case when you develop it 😉