This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-11
Channels
- # admin-announcements (3)
- # beginners (51)
- # boot (14)
- # cider (55)
- # cljsrn (5)
- # clojure (105)
- # clojure-austin (2)
- # clojure-brasil (3)
- # clojure-dusseldorf (2)
- # clojure-greece (5)
- # clojure-italy (1)
- # clojure-mexico (1)
- # clojure-russia (74)
- # clojure-spec (66)
- # clojure-uk (22)
- # clojurescript (124)
- # cursive (10)
- # datomic (79)
- # events (2)
- # immutant (3)
- # jobs (4)
- # klipse (38)
- # leiningen (2)
- # luminus (1)
- # off-topic (25)
- # om (48)
- # om-next (36)
- # on (1)
- # onyx (19)
- # overtone (3)
- # pedestal (2)
- # proton (3)
- # re-frame (178)
- # reagent (49)
- # ring-swagger (1)
- # spacemacs (10)
- # specter (29)
- # testing (5)
- # untangled (6)
- # yada (65)
@jmglov did you ever get around to doing this: https://clojurians-log.clojureverse.org/clojure-spec/2016-09-12.html#inst-2016-09-12T18:28:43.000617Z
or is there an updated way to integrate clojure.spec generative tests into your lein test
runs?
@alexmiller has there been any consideration put toward separating required semantics from s/keys
, and creating another function s/required
?
I have a spec which uses s/fspec
(`:args` specified). As you know, this spec requires test.check
. Is there a way to temporary skip validating s/fspec
so that I can execute s/valid?
on this spec at runtime?
You can instrument and supply a spec override to ifn?
My code is in this shape
(def fn1 [body])
(def fn2 [body])
; ... fnN
(s/def ::a-fn (s/fspec :args (s/cat :body string?)))
(s/def ::a-map (s/keys :opt-un [::a-fn]))
(s/valid? ::a-map {:a-fn fn1})
(s/valid? ::a-map {:a-fn fn2})
I'll need to stub fn1,fn2,...,fnN, right? Maybe I should structure my code differently then.almost suggested the xform thing, but I am not sure it will work with the advanced stuff (instrumentation)
so, perhaps an odd question, but is there a clojure 1.9 build that is production ready? I want to use spec, but being the guy that insists we put an incomplete version of clojure in prod is a bit nerve racking
if it's only validation yes, I was referering to this kind of issue: http://dev.clojure.org/jira/browse/CLJ-1936
tjtolton clojure 1.9 is still alpha, no word on when the official release will be out yet
is it a good idea for me to try to get spec into our code now? or should I wait, and just keep using spec in toy projects until the official release
That’s a judgement call only you can make. spec is still alpha and subject to change. We are aware of the desire from many directions to have a 1.9 (non-alpha) with spec available.
@cgrand yes, it's an option. I was interested in specing promise-chans which should return a specific type of value.
@lmergen cool. I'm going to basically hook up 1.9-alpha and spec to the service that I'm the owner of.
@tjtolton: we've been running Clojure 1.9 in production for months with no problems. We've always run alpha and beta builds in production as they've appeared in order to leverage new features early. We first went to production on Clojure 1.3 alpha 7 or 8 back in 2011.
I think in nearly seven years we’ve seen just two builds with production-affecting bugs. We skipped one of those (just a matter of timing, due to when our production builds fell, either side of that release), and the other one was fixed quickly enough that we just pushed a new production build with the updated Clojure JAR.
Like every single thing in life, it comes down to a simple ratio of risk:reward. If the code won’t run on 1.8, and if the consequences of delaying a production release are worse than the consequences of a production product exploding (i.e., first to get to market on something may be most important than it actually working well), then it might make sense to use a 1.9 alpha in production. Also, if the user impact is low (i.e., this isn’t a mission critical application and several hours/days of downtime won’t kill anyone) then it might also make sense. However, as a general process, it just doesn’t make sense to run alpha in production. The liability is all on you. I prefer to shift liability elsewhere when it’s pragmatic to do so, and when the clojure core code is considered “production ready” and it fails, the liability has at least partially shifted away from you as the developer, and onto the clojure core team. For products with relatively low use, I’d run an early alpha in production since the track record seems to be good. But for a service which receives several thousands of requests per second, around the clock, and upon which many millions of dollars hang — for us personally, being able to run spec isn’t worth that risk, i.e., we can wait a few months. Each developer and team has to make the call and accept the consequences 🙂
Is it a design goal of clojure.spec (and the core specs in particular) that conform/unform should always round-trip? For instance, the built-in spec for defn-args
doesn’t round-trip in at least one case (more details http://blog.klipse.tech/clojure/2016/10/10/defn-args.html) - is that considered a bug?
The reason I ask is that we’re experimenting with using the conform+modify+unform pattern for modifying data, and just wondering if the core specs will be written to support that
There are currently some known bugs in unform
based on discussions I’ve seen here.
it seems like having unform
be able to roundtrip successfully in all cases is a tricky situation
@mikerod can you talk a little more about that? “tricky” as in there’s going to be a long-tail of bugs for this? or “tricky” as in “it’s not realistic to treat every case as a bug”? or something else?
@bbrinck oh, I’m just hypothesizing and considering how I’ve seen the topic come up quite a few times.
I actually don’t know. I do hope that it is meant to be able to do the type of roundtripping you are going for in you defn-args article though
Oh, to be clear, I didn’t write that post - we just used it as a starting point for writing our macro
yes, conform -> unform should roundtrip (with a few caveats)
there are some known issues http://dev.clojure.org/jira/browse/CLJ-2076 (coll-of, map-of) http://dev.clojure.org/jira/browse/CLJ-2003 (s/?)
and then I'd say one area that could benefit from something additional is specifically for specs that are using regexes in a vector - some of the core macro specs suffer from this and unform to a list rather than a vector. that’s a common and important case and I think we need something specific for it (whether that’s creating vcat or something else is TBD)
that’s the case mentioned at the top of this conversation
if you find something else, feel free to file a bug
@tjtolton: Another option is to run clojure 1.9alphas in dev/test profile's only and have a policy to avoid including 1.9 features in the production environment.... you can set this up with leiningen profiles pretty easily. This way you could e.g. write specs in your unit tests, but not put them in the production code itself, keeping it on 1.8 … when spec is finally released you could then move some of the specs out of the tests into the production code. You could also switch to 1.9 whenever you want and know you can switch back if it’s not good. Obviously it requires some discipline, and might mean you can’t test code in the production env; so there’s still some significant risk - and you might also want to separate the 1.9 tests into a separate profile. Anyway it’s just one possibility I’ve been considering
The core team are incredible at keeping clojure stable though - but it’s alpha for a reason, so we should respect that they may want to change their minds and make significant changes to 1.9 code at any point.
I’d add the caution that there are quite a lot of oh-so-convenient new predicate functions in 1.9 that you’ll find hard to resist using in your code and then you’ll be unable to run on 1.8. You’ll also be forced into keeping all the spec stuff in separate namespaces so your non-test code will run on 1.8.