Fork me on GitHub

Hey, trying to setup deps.edn correctly (I kinda miss easiness of lein ;/):

{:paths ["src"]
   {: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' (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.


That commit is before cognitect.test-runner.api namespace was added


the only namespace in the project at that point is cognitect.test-runner


if you use

:extra-deps {io.github.cognitect-labs/test-runner
                 {:git/tag "v0.5.0" :git/sha "b3fd0d2"}}
it should work


Thanks, thanks - yeah it start but doesnt discover tests ;/

Alex Miller (Clojure team)15:06:14

by default it looks for tests with:

:patterns [".*-test$"]

Alex Miller (Clojure team)15:06:05

you might need to supply :dirs or :patterns that match your project


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

getting Ran 0 tests containing 0 assertions.


might be an underscore issue? Rename it to basic_test.clj


yeah, always the dash stuff gets messy, thanks


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


it did in the end 🙂

👍 1

thanks, still deps needs some "easy" templates 🙂


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 for creating new projects from simple app and lib templates?


no i meant for easy reuse of common build tasks (making uberjars, jars, etc)


Ah, to fill the "leiningen gap", right.

👍 1

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!

🎉 3
🙂 2

I resolved that 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.

Alex Miller (Clojure team)19:06:26

very hard to tell as you have now deleted the evidence :)

Alex Miller (Clojure team)19:06:47

may I suggest in the future renaming the ~/.m2/repository folder instead...


Are there any common mistakes that people make to corrupt it?

Alex Miller (Clojure team)19:06:24

nothing that makes sense to me with the problem above

Alex Miller (Clojure team)19:06:01

from that stack trace, the:

at clojure.lang.RT.readString(
	at clojure.lang.RT.readString(
	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 anything

Alex Miller (Clojure team)19:06:00

you also had middleware in play and that stuff may have special printers for uuids that could affect things

Alex Miller (Clojure team)19:06:36

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.
(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
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.
user=> (identity #uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978")
#uuid "0eb537e1-72bc-4d1a-89e0-8e3c2a7f8978"


Do you have a deps.edn in the folder where you are running clj? If so, what is in it?

Alex Miller (Clojure team)19:06:36

(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:


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)

Alex Miller (Clojure team)19:06:00

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


It was right in /tmp and there's still no deps.edn there.


Anyway, as @U064X3EF3 said, I shouldn't have thrown away the evidence.

Alex Miller (Clojure team)19:06:51

but you may have ~/.clojure/deps.edn that affects it

Alex Miller (Clojure team)19:06:08

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.


And /usr/local/lib/clojure/deps.edn was commented out.


@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

Alex Miller (Clojure team)20:06:44

> 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

Alex Miller (Clojure team)20:06:28

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.

Alex Miller (Clojure team)20:06:49

assuming that's the root deps.edn, that's not actually used

Alex Miller (Clojure team)20:06:51

still interested in clj --version

Alex Miller (Clojure team)20:06:58

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


I can no longer reproduce it.

Alex Miller (Clojure team)20:06:02

that's a pretty old version now (latest is, 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.

Alex Miller (Clojure team)20:06:04

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

Alex Miller (Clojure team)20:06:48

I don't see any evidence to support that theory with that clj output though


Ah yes, upgraded to now.

Alex Miller (Clojure team)20:06:52

I don't know of any non-cljs stuff that has had any issue like that with uuid tagged literals either

Alex Miller (Clojure team)20:06:32

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

Alex Miller (Clojure team)20:06:10

and then you get

user=> (.toString (random-uuid))

Alex Miller (Clojure team)20:06:49

if you read that string, then you're at the error


Why would passing the uuid to do work, but not identity?

Alex Miller (Clojure team)20:06:56

I don't know why any of them wouldn't work


do, and, or accepted it fine. identity, prn did not.


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


But if it's a printer issue, all of them would have been impacted equally, no?

Alex Miller (Clojure team)20:06:36

well, could be a read issue too. I assume you don't have a tmp/src/data_readers.clj


Nope, I didn't have custom readers.


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.

Alex Miller (Clojure team)20:06:28

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


so the uuid passed in would need to be serialized, then deserialized


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)


you can see in where in printing a level of quoting is lost, which would lead to the uuid attempted to be read as a number


(why #uuid would be an unknown tag, I dunno)


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


But wouldn't that impact identity and the plain literal in the same way?


They both end up printing the re-instantiated UUID, no?


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


user-loaded in the output makes me deeply suspicious


oh, I was reading the wrong example there


it is really unfortunate not to have a stacktrace from the non-shadowcljs repl


because line 28 of;origin_channel=Vall_threads shows the static init of the class from compiling the shadow.user namespace being run, and the error happening then


Yes 😞 I will do better next time.


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