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

No

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

hola spec'ers

are there precedent to people using specs with channels?

(as in c.c.async channels)

if you mean specing what's inside of them no, specing channels as "values" yes

as for instrumentation I bet it's hairy territory but I never tried tbh

the former is what i meant

meh, no worries

@pyr a/chan + conforming|validating transducer + ex-handler?

almost suggested the xform thing, but I am not sure it will work with the advanced stuff (instrumentation)

which interaction do you see between a channel and an instrumented defn?

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

arg gen triggered by fdef for instance

so far it has been one of the thing I have found quite confusing/surprising

I guess as long as the fn is pure it's ok

@mpenet: I see: not instrumentation but validation of a fspec

if it's only validation yes, I was referering to this kind of issue: http://dev.clojure.org/jira/browse/CLJ-1936

I mixed fdef and fspec earlier tho

tjtolton clojure 1.9 is still alpha, no word on when the official release will be out yet

gotcha. so, officially, no guarantees on spec in production

but

unofficially

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.

@tjtolton we're running spec in production. haven't found any problems, but YMMV

(we're also running aleph and manifold alpha's in production, so there's that)

@lmergen cool. I'm going to basically hook up 1.9-alpha and spec to the service that I'm the owner of.

If it breaks, it will be my job to fix it, which I'm cool with.

i hope you're not in charge of the authorization service then 😉

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

good thing clojure is stable as hell

God I love this language culture.

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

@mikerod ah, i see. for now, we just ended up writing our own spec for this case

I’m definitely not going to give any definitive say on it though 😛

🙂

Yeah, I saw you mentioned adding a conformer

Oh, to be clear, I didn’t write that post - we just used it as a starting point for writing our macro

but it’s a good explanation of the issues we ran into

ah, I misread that part

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

OK, that’s very helpful. Thanks!

if you find something else, feel free to file a bug

thanks!

for the details

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