This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-29
Channels
- # announcements (6)
- # beginners (110)
- # calva (18)
- # clj-kondo (19)
- # cljs-dev (27)
- # clojars (10)
- # clojure (38)
- # clojure-art (2)
- # clojure-europe (13)
- # clojure-germany (1)
- # clojure-norway (26)
- # clojure-uk (2)
- # clojurescript (10)
- # conjure (9)
- # cursive (12)
- # data-science (3)
- # datomic (22)
- # emacs (8)
- # helix (9)
- # honeysql (18)
- # introduce-yourself (1)
- # jobs (1)
- # leiningen (8)
- # lsp (22)
- # missionary (9)
- # nbb (11)
- # off-topic (83)
- # pathom (5)
- # pedestal (4)
- # polylith (1)
- # portal (1)
- # re-frame (3)
- # reitit (15)
- # remote-jobs (1)
- # rum (4)
- # shadow-cljs (88)
- # specter (12)
- # testing (1)
- # vim (39)
Hey, trying to setup deps.edn correctly (I kinda miss easiness of lein ;/):
{:paths ["src"]
:aliases
{:test {:extra-paths ["test"]
:main-opts ["-m" "cognitect.test-runner"]
:exec-fn cognitect.test-runner.api/test
:extra-deps {com.cognitect/test-runner
{:git/url ""
:sha "f7ef16dc3b8332b0d77bc0274578ad5270fbfedd"}}}}}
When running clj -X:test
I am getting:
Execution error (FileNotFoundException) at clojure.run.exec/requiring-resolve' (exec.clj:31).
Could not locate cognitect/test_runner/api__init.class, cognitect/test_runner/api.clj or cognitect/test_runner/api.cljc on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
if you use
:extra-deps {io.github.cognitect-labs/test-runner
{:git/tag "v0.5.0" :git/sha "b3fd0d2"}}
it should workby default it looks for tests with:
:patterns [".*-test$"]
you might need to supply :dirs
or :patterns
that match your project
https://github.com/cognitect-labs/test-runner#invoke-with-clojure--x-exec-style has the logic for test finding
hmmm... my tree looks like
- src/
- test/
- basic-test.clj
my basic-test.clj
:
(ns basic-test
(:require [clojure.test :refer [deftest run-all-tests]]))
(deftest simple
(println "Hi"))
(run-all-tests)
getting Ran 0 tests containing 0 assertions.
did that solve it? I recreated that scenario and it threw an error so perhaps that wasn’t your issue
❯ tree
.
├── deps.edn
└── test
└── foo_test.clj
1 directory, 2 files
/tmp/neil via :coffee: v17.30 on :cloud: metabase-query
❯ cat deps.edn
{:aliases {
:test ;; added by neil
{:extra-paths ["test"]
:extra-deps {io.github.cognitect-labs/test-runner
{:git/tag "v0.5.0" :git/sha "b3fd0d2"}}
:main-opts ["-m" "cognitect.test-runner"]
:exec-fn cognitect.test-runner.api/test}}}
/tmp/neil via :coffee: v17.30 on :cloud: metabase-query
❯ cat test/foo_test.clj
(ns foo-test
(:require [clojure.test :refer [deftest is]]))
(deftest foo
(is (= 1 2)))
this scenario works for me with clj -X:test
I did neil add test
and got all of this for free. There is also another lib [email protected]:seancorfield/build-clj.git
One reason why I much prefer this vs the lein stuff is that in both cases they are just little programs. But debugging why lein uberjar
did or did not pick up a license file and put it in your jar is incredibly difficult. These new programs are just simple programs you can run from a repl. Debugging lein is so painful
@U11BV7MTK Did you mean https://github.com/seancorfield/deps-new for creating new projects from simple app
and lib
templates?
yeah. At one point i thought about just extracting all of the leiningen “tasks” so you could do things like clj -X:lein uberjar
and it would do exactly what those tasks used to do. But I think it was hard to extract all of the lein project stuff in those tasks. And then things like your project came about
I went from lein
to boot
in 2015 and from boot
to CLI / deps.edn
in 2018 and I do not miss Leiningen 🙂
i agree. although it was nice that you could easily get an uberjar from a base project. I think neil
is killer in this regard. Makes a tutorial or repro very easy to do
In about 1 hour we will be having a beginner friendly zoom meetup where we help answer YOUR questions about getting started using Clojure(script). Join myself, @plexus @nonrecursive @quoll and @mfikes! Head on over to #the-clouncil channel for zoom link!
I resolved that https://clojurians.slack.com/archives/C053AK3F9/p1656459991560439 with UUIDs that I reported yesterday by deleting my ~/.m2
folder and re-installing Clojure.
Can anyone suggest how my .m2 might be getting screwed up, how I could avoid it and/or how to detect such a problem before spending a time chasing dead ends? I'm not manually interacting with that folder at any time, so I'm very confused as to what's happening here.
very hard to tell as you have now deleted the evidence :)
may I suggest in the future renaming the ~/.m2/repository folder instead...
nothing that makes sense to me with the problem above
from that stack trace, the:
at clojure.lang.RT.readString(RT.java:1876)
at clojure.lang.RT.readString(RT.java:1871)
at com.example.playgrounds.pathom$eval123662.<clinit>(NO_SOURCE_FILE:122)
was the most suspicious part of it - somehow pathom was reading the id part of the uuid as a number. not sure how pathom is involved or whether that makes you think of anythingyou also had middleware in play and that stuff may have special printers for uuids that could affect things
none of that makes any sense with cleaning your m2 though, unless that had a side effect of moving you to a newer version of something
com.example.playgrounds.pathom
is just a namespace I use to experiment with Pathom stuff, so it stays out of source control. I don't think it's relevant.
Earlier today I recreated the issue with just:
$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.1"} meander/epsilon {:mvn/version "0.0.650"}}}'
Clojure 1.11.1
(identity #uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978")
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"
(require '[meander.epsilon :as m])
Reflection warning, meander/util/epsilon.cljc:758:24 - reference to field val can't be resolved.
nil
(identity #uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978")
Execution error (NumberFormatException) at user$eval11419/<clinit> (REPL:1).
Invalid number: 0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"
Here's what I see for those commands:
seanc@Sean-win-11-laptop:~/clojure$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.1"} meander/epsilon {:mvn/version "0.0.650"}}}'
Downloading: meander/epsilon/0.0.650/epsilon-0.0.650.pom from clojars
Downloading: meander/epsilon/0.0.650/epsilon-0.0.650.jar from clojars
user-loaded
Clojure 1.11.1
d "0eb5(identity #uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978")
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"
user=> (require '[meander.epsilon :as m])
Reflection warning, meander/util/epsilon.cljc:758:24 - reference to field val can't be resolved.
nil
user=> (identity #uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978")
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"
user=>
Do you have a deps.edn
in the folder where you are running clj
? If so, what is in it?
(pst *e)
would be of interest as well
> Do you have a deps.edn in the folder where you are running clj? If so, what is in it?
No, I ran it right in my /tmp
.
At one point I thought it was a shadow issue, so there's some shadow-cljs stuff sprinkled in here. Closest I have to *e
:
https://clojurians.slack.com/files/UPWHQK562/F03MM8RAMEZ/untitled.txt
Given the presence of socket REPL stuff in there and Shadow-cljs being in play, this sounds more like a bug in Shadow-cljs and/or some interaction with Meander and Shadow-cljs so maybe ask in #shadow-cljs because thheller
is not in the #beginners channel...
I suspect it's some sort of problem with round-tripping your UUID strings thru the socket REPL that Shadow-cljs is using, that ends up getting an unadorned "0eb..." and ends up trying to read that string as a Clojure value, which throws because 0eb...
is not a valid number.
I had this talk with thheller but then I was able to isolate the issue away from shadow-cljs to that snippet that you tried, @U04V70XH6. The stacktrace is just the closest that I have still sitting around, so I posted it, thinking maybe it could offer clues nonetheless.
Well, I typed in exactly the same clj
command and expressions you showed and it worked -- see my paste above. Are you sure that running that command and entering those expressions, in a fresh directory with no other deps, really fails for you?
Something to try:
seanc@Sean-win-11-laptop:~/clojure$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.1"} meander/epsilon {:mvn/version "0.0.650"}}}' -Stree
org.clojure/clojure 1.11.1
. org.clojure/spec.alpha 0.3.218
. org.clojure/core.specs.alpha 0.2.62
meander/epsilon 0.0.650
(just so we can eliminate any rogue deps coming in from your dot-clojure file or some other source)+1 to what Sean said... these two things seem like independent use cases and I agree with Sean's theory on the shadow side. I also cannot repro the standalone case with clj.
It did, yes. I am sure because I have the terminal where I did it still open, and I can see myself looking for a deps.edn after issuing the command.
Anyway, as @U064X3EF3 said, I shouldn't have thrown away the evidence.
but you may have ~/.clojure/deps.edn that affects it
I guess also interested in clj --version
Yes, I have ~/.config/clojure/deps.edn
, but it only has aliases in it, and I wasn't activating those.
@UPWHQK562 Can you run the -Stree
command I posted above, just to check the result?
/tmp$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.1"} meander/epsilon {:mvn/version "0.0.650"}}}' -Stree
org.clojure/clojure 1.11.1
. org.clojure/spec.alpha 0.3.218
. org.clojure/core.specs.alpha 0.2.62
meander/epsilon 0.0.650
> And /usr/local/lib/clojure/deps.edn
was commented out.
commented out of ... what?
> I guess also interested in clj --version That's printed at the top of the snippet, I believe:
$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.1"} meander/epsilon {:mvn/version "0.0.650"}}}'
Clojure 1.11.1
no, that's the Clojure version, not the CLI version
> commented out of ... what? I commented out the contents and just left an empty map.
assuming that's the root deps.edn, that's not actually used
still interested in clj --version
and wondering if you can still reproduce this now or if not after the m2 wipe
Okay, so not relevant. I wanted to remove all configs that were potentially included. Is there an easier way to do that, BTW? Vim has vim -u NONE
flag to avoid user settings/plugins.
> still interested in clj --version
I don't have what it was before, unfortunately. Now it's:
$ clj --version
Clojure CLI version 1.10.3.855
that's a pretty old version now (latest is 1.11.1.1149), and there were some concurrency issues that could lead to issues in Maven downloads that have been fixed since, but I can't see any way those issues would result in what you're seeing, which feels like some kind of print tooling
I think that's what got installed with brew install clojure/tools/clojure
on Linux.
the #uuid should be read as a java.util.UUID, evaled to itself, and printed using the builtin UUID printer
my guess would be you where using a SNAPSHOT version of some tooling, which the latest snapshot got downloaded once, a long time ago, and you've been on that old snapshot version for a while, and that old snapshot version of whatever tool had a a bug related to tagged literals
I don't see any evidence to support that theory with that clj output though
I don't know of any non-cljs stuff that has had any issue like that with uuid tagged literals either
I can imagine maybe two versions of the UUID class in different classloaders and print support was installed on a different one than you had an object for for example
reply (the nrepl client) had some kind of issue with completion of tagged literals that was similar if I recall
and then you get
user=> (.toString (random-uuid))
"59e68557-1a8b-48b3-97f5-1a38205ae15b"
if you read that string, then you're at the error
I don't know why any of them wouldn't work
And of course just the tagged literal #uuid "59e68557-1a8b-48b3-97f5-1a38205ae15b"
also worked fine.
the difference between those identity and prn are functions, do is a special form, and and or are macros that expand to special forms
well, could be a read issue too. I assume you don't have a tmp/src/data_readers.clj
Sorry guys, I don't mean to consume so much of your time. It's my bad for deleting the folder instead of just moving it. If there is no general advice about avoiding/troubleshooting/detecting things like this in the future I think we can lay this one to rest unless it springs up again.
meander does, but not for this
complicated, I would say so, but in theory if the repl was compiling the calls like (identity ...)
instead of passing them through the interpreter (which it should do for such simple things, but again if you have any middleware wrapping forms to be evaluated that could change things) then the arguments would need to be embedded in byte code
I appreciate the input and insights as to potential causes. A good learning experience anyhow.
so the uuid object you got back might not be the same object that you passed in (if the call to identity got byte code compiled)
sounds vaguely like this https://github.com/nrepl/piggieback/issues/120
you can see in https://github.com/lambdaisland/deja-fu#piggieback-printing where in printing a level of quoting is lost, which would lead to the uuid attempted to be read as a number
I did print out my *data-readers*
at one point during the troubleshooting:
shadow.user=> *data-readers*
{dbg #'cider.nrepl.middleware.debug/debug-reader, break #'cider.nrepl.middleware.debug/breakpoint-reader, light #'cider.nrepl.middleware.enlighten/light-reader, meander.epsilon/fail #'meand
er.strategy.epsilon/*fail*, meander.epsilon/pass #'meander.strategy.epsilon/*pass*}
so the lack of uuid there is not a smoking gun, because it usually doesn't show up there, because it is part of a default set of literals that is merged into that map
but if you are interacting with the reader directly, like some naive tooling may be, and you fail to merge in the defaults, uuid would be missing, which might then trigger the above linked issue
no, the java code for reading edn appears to merge in the defaults, so that doesn't explain how a uuid would be an unknown literal
and I am pretty sure looking at the original stacktrace, the issue is happening when trying to read-string(reinstantiate) a uuid that had been serialized into byte code using pr-str
so possibly you hit the piggieback bug there while aot compiling, the uuid was incorrectly serialized when generating byte code as a result, and then at a later date(possible much later) when loading and running the byte code (possible from disk) the deserialization failed
it is potentially very complicated, once you start adding cljs tooling to the repl (shadowcljs, piggieback) there is much more code being run there
Yes, I recognize that while walking through it earlier. I thought that my last snippet isolated it from just about everything though. Is there a common approach to creating an isolated repro?
huh, sorry, my slack seems to already be having trouble with the size of this thread, so I missed that
because line 28 of https://clojurians.slack.com/files/UPWHQK562/F03MM8RAMEZ/untitled.txt?origin_team=T03RZGPFR&origin_channel=Vall_threads shows the static init of the class from compiling the shadow.user namespace being run, and the error happening then
it would have been interesting to see what you had for meander/epsilon version 0.0.650 in your m2 as well, because while there is a jar for that in clojars, there doesn't appear to be a tag for it in https://github.com/noprompt/meander