This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-09
Channels
- # announcements (16)
- # beginners (86)
- # calva (4)
- # cider (17)
- # circleci (1)
- # clj-kondo (4)
- # cljs-dev (12)
- # cljsrn (4)
- # clojure (82)
- # clojure-europe (2)
- # clojure-houston (4)
- # clojure-italy (5)
- # clojure-nl (7)
- # clojure-spec (49)
- # clojure-uk (19)
- # clojurescript (76)
- # core-async (7)
- # cursive (1)
- # data-science (4)
- # datomic (5)
- # figwheel (1)
- # fulcro (10)
- # graalvm (15)
- # jobs (1)
- # juxt (6)
- # kaocha (2)
- # leiningen (5)
- # random (2)
- # shadow-cljs (25)
- # sql (5)
- # tools-deps (113)
- # vim (3)
- # yada (14)
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
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
https://github.com/clojure/spec-alpha2#releases-and-dependency-information
@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
(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
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 clojure.java.jdbc
that I have maintained for about eight years!)
@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.
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.
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
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"}}