Fork me on GitHub
#clojure-spec
<
2019-08-09
>
valerauko03:08:33

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

Alex Miller (Clojure team)03:08:21

roadmap in terms of things to do or timing

Alex Miller (Clojure team)03:08:40

I guess you mean timing

Alex Miller (Clojure team)03:08:06

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

šŸ‘ 4
valerauko03:08:13

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

Alex Miller (Clojure team)03:08:30

well, you might be fine then

Alex Miller (Clojure team)03:08:52

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

seancorfield03:08:30

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

Alex Miller (Clojure team)03:08:14

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

šŸ’Æ 12
šŸ‘ 4
seancorfield03:08:35

(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!)

valerauko03:08:21

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

valerauko03:08:09

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

valerauko04:08:53

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

seancorfield04:08:03

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

seancorfield04:08:33

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

seancorfield04:08:41

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.

seancorfield04:08:45

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.

Alex Miller (Clojure team)04:08:13

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

Alex Miller (Clojure team)04:08:14

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

Alex Miller (Clojure team)04:08:57

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

Alex Miller (Clojure team)04:08:16

the api is pretty stable there

seancorfield04:08:39

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

seancorfield04:08:53

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

valerauko05:08:00

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

seancorfield05:08:59

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

seancorfield05:08:47

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.

seancorfield05:08:26

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.

seancorfield05:08:50

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

dharrigan08:08:15

upvote for add-lib in tools.deps please šŸ™‚

āž• 24
ikitommi11:08:22

@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 https://clojure.atlassian.net/browse/CLJ-2116, 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.

Alex Miller (Clojure team)11:08:37

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

Alex Miller (Clojure team)11:08:19

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

Alex Miller (Clojure team)11:08:57

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

ikitommi11:08:42

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.

Alex Miller (Clojure team)11:08:09

Well, weā€™re working on the walking stuff too

šŸ‘ 4
ikitommi11:08:15

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

Alex Miller (Clojure team)11:08:13

The other half of what Iā€™m working on now is dataficatiom of specs

ikitommi11:08:50

cool. just for browsing or also transforming?

Alex Miller (Clojure team)11:08:17

Either - the input side is there now

Alex Miller (Clojure team)11:08:53

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

ikitommi11:08:42

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.

Alex Miller (Clojure team)11:08:59

Havenā€™t really considered it. Why not just use select-keys?

ikitommi11:08:26

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

Alex Miller (Clojure team)11:08:13

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

Alex Miller (Clojure team)11:08:10

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

ikitommi11:08:23

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"}}

ikitommi11:08:46

spec-tools does that nowadays with form walking btw.

ikitommi11:08:07

I think that would use the upcoming ā€œwalkerā€, so a good test case when you develop it šŸ˜‰