Fork me on GitHub
#clojure-spec
<
2018-09-28
>
manutter5109:09:02

I’m trying to run (stest/instrument) in a clojurescript repl, but I can’t even get that far:

dev:cljs.user=> (require '[cljs.spec.test.alpha :as stest])
----  Could not Analyze    ----

  No such namespace: clojure.test.check, could not locate clojure/test/check.cljs, clojure/test/check.cljc, or JavaScript source providing "clojure.test.check" in file file:/Users/mark/.m2/repository/org/clojure/clojurescript/1.10.339/clojurescript-1.10.339.jar!/cljs/spec/test/alpha.cljs

----  Analysis Error  ----

manutter5109:09:00

:dependencies [[org.clojure/clojure "1.9.0"]
               [org.clojure/clojurescript "1.10.339"]
               [org.clojure/spec.alpha "0.2.176"]

manutter5109:09:01

Am I missing a step somewhere?

manutter5109:09:38

I just added the explicit dependency on spec.alpha 0.2.176 this morning, but it makes no difference, I get the same error either way.

valerauko09:09:13

i thought you needed to depend on clojure.test for generating etc

manutter5110:09:15

You ought to be able to load the namespace though, right?

manutter5110:09:10

I’m spinning up a brand new REPL, and the first thing I type is the require, and it won’t load the namespace.

manutter5110:09:53

Hmm, something odd in lein deps :tree too:

[org.clojure/clojure "1.9.0"]
   [org.clojure/core.specs.alpha "0.1.24"]
“specs” plural? What’s that?

mgrbyte11:09:05

I think they are the specs that have been added for clojure language itself.

manutter5111:09:09

Ah, that would make sense.

manutter5111:09:15

So is anybody else having this problem? Can’t require the cljs.spec.test.alpha ns in a freshly-started REPL?

manutter5111:09:31

It does seem suspicious that it’s looking for it specifically inside the clojurescript jar when I have a perfectly good clojure jar on the same classpath.

athos11:09:37

Probably that can be fixed by adding test.check https://github.com/clojure/test.check to your dependencies.

manutter5122:09:11

I didn’t get to it on my lunch break, but I just now added the dependency to test.check, and it works great! Thanks a ton! 😄

manutter5112:09:16

Ok, thanks, I'll try that on my lunch break; got to start day job now.

😉 4
urzds12:09:54

Hi! I just tried to update to Clojure 1.9 and get weird errors when building my code: :cause Call to clojure.core/refer-clojure did not conform to spec: Sadly this error message is so convoluted that I cannot even figure out which file is causing this. Any idea what to look for?

urzds12:09:19

(We do not use spec ourselves.)

mpenet13:09:01

you likely have malformed ns declaration(s)

mpenet13:09:59

or one of your deps

favila13:09:34

Unfortunately the error will say it is coming from the requiring ns instead of the file it is in

favila13:09:59

The ns form isn’t been evaluated yet (because it has an error) so the current ns ( as shown in the message) is still the requiring one

urzds15:09:32

@mpenet, @favila: So the namespace that requires the broken namespace is the one mentioned in the LOAD FAILURE for <ns> line?

favila15:09:58

that's been my experience, yes

urzds15:09:52

Any idea what this spec problem report might be hinting at? https://gist.github.com/urzds/880cd51851a248230861b178c7d6b986

urzds15:09:38

Also, in the backtrace it mentions a different file from the namespace it mentions in the LOAD FAILURE for ... line.

urzds15:09:34

So my guess would be that the file it mentions in the backtrace actually contains something funny. But I have no idea what I am looking for...

dadair15:09:28

Looks like it is complaining about the “:as core” part

seancorfield15:09:44

Yeah, the syntax is (:refer-clojure :exclude [...]) -- that :as core part is what is blowing up.

seancorfield15:09:25

@urzds if you post a Gist of your dependencies and/or the full stacktrace, we can probably narrow it down for you.

seancorfield15:09:43

Also @urzds check out this page and see if any of your dependencies are listed there https://dev.clojure.org/display/design/Errors+found+with+core+specs

urzds15:09:37

Different question (I am trying to stay on 1.8 and first make sure all my deps are still working): Is it possible to hot patch a function into clojure.core? Lacinia Pedestal is broken on Clojure 1.8, because it uses a function from 1.9: https://github.com/walmartlabs/lacinia-pedestal/issues/80

seancorfield16:09:23

@urzds Is there a pressing reason to stay on 1.8?

seancorfield16:09:47

(I think, yes, you can define your own clojure.core/pos-int? but you'd need to do it somehow before that Lacinia namespace was even loaded so...)

urzds16:09:06

@seancorfield No pressing need. But before I try to upgrade to Clojure 1.9, I want to make sure everything still works after upgrading all my deps to versions that should in theory be capable of supporting 1.9.

seancorfield16:09:59

I suspect you'll be caught between a rock and a hard place there with anything that already uses clojure.spec since such code may assume a number of things present in 1.9 -- although I thought clojure-future-spec was supposed to patch those up as well?

seancorfield16:09:10

Ah, I see... it expects you to (:require [clojure.future :refer :all]) into the spec-using namespace but doesn't add anything to clojure.core directly. So it only helps you use clojure.spec in your own code -- that's not going to help with any other code that already assumes 1.9+.

urzds16:09:24

Ah, but that's nice. I am right now writing my own shim... 😄

urzds16:09:50

So I'll just patch up lacinia-pedestal with clojure.future instead of my own shim.

seancorfield16:09:46

Yeah, I think you'll have to fork lacinia-pedestal for now, patched with clojure.future, and then revert to the official version when you're ready to move to 1.9.

seancorfield17:09:21

But, frankly, I would consider that a waste of effort and just go ahead with the 1.9 upgrade and do any necessary work there instead.

urzds17:09:26

Yes, but they even claim to support Clojure 1.8, so it's actually a bugfix. I'll just send them a PR.

seancorfield17:09:22

But on 1.8, doesn't it just not use clojure.spec? That's how most of the libraries seem to handle 1.8 compatibility when they have specs?

urzds17:09:38

Not this one... 😞

seancorfield17:09:09

So it already assumes clojure-future-spec is being used? That's kinda odd...

seancorfield17:09:41

Ah... and then clearly don't test against that setup 🙂

seancorfield17:09:24

Overall tho', I still suspect you'd have a lot less pain trying Clojure 1.9 directly instead of all this working-around-spec on 1.8 🙂

seancorfield17:09:32

Probably a good idea to create an issue (or send them a PR) to add a :1.8 alias to project.clj with Clojure 1.8 and clojure-future-spec so it's easy to test with in the future (and they could auto-test against both 1.8 and 1.9 on CircleCI).

urzds17:09:42

@seancorfield Thanks for all your help! I don't really know what you refer to with the last line, though.

urzds17:09:15

Now the spec violations vanished. That's weird...

urzds17:09:26

Probably it was good that I tinkered with the different dependencies for so long. Maybe cheshire or commons-codec or commons-io or org.clojure/tools.reader were causing it, because now I :exclude them from deps that request older versions and my code suddenly compiles...

lilactown17:09:41

I have a map of var-quoted functions that I'm using as a lacinia resolver map. After add fspecs for all of them and turning on instrumentation, I'm getting this error:

com.fasterxml.jackson.core.JsonGenerationException: Cannot JSON encode object of class: class clojure.spec.alpha$regex_spec_impl$reify__2436: clojure.spec.alpha$regex_spec_impl$reify__2436@29cbdd3c