Fork me on GitHub
#beginners
<
2022-06-29
>
rmxm15:06:48

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.

dpsutton15:06:35

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

dpsutton15:06:52

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

dpsutton15:06:20

if you use

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

rmxm15:06:27

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

rmxm15:06:10

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.

dpsutton15:06:03

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

rmxm15:06:33

yeah, always the dash stuff gets messy, thanks

dpsutton15:06:09

did that solve it? I recreated that scenario and it threw an error so perhaps that wasn’t your issue

dpsutton15:06:22

❯ 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

rmxm15:06:24

it did in the end 🙂

👍 1
rmxm15:06:25

thanks, still deps needs some "easy" templates 🙂

dpsutton15:06:07

I did neil add test and got all of this for free. There is also another lib [email protected]:seancorfield/build-clj.git

dpsutton15:06:48

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

seancorfield16:06:54

@U11BV7MTK Did you mean https://github.com/seancorfield/deps-new for creating new projects from simple app and lib templates?

dpsutton16:06:34

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

seancorfield16:06:54

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

👍 1
dpsutton16:06:44

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

seancorfield16:06:42

I went from lein to boot in 2015 and from boot to CLI / deps.edn in 2018 and I do not miss Leiningen 🙂

dpsutton16:06:25

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

lambduhhh15:06:19

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
sheluchin19:06:45

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.

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

sheluchin19:06:04

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

sheluchin19:06:57

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"

seancorfield19:06:02

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=>

seancorfield19:06:20

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

sheluchin19:06:29

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

sheluchin19:06:48

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

seancorfield19:06:21

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

seancorfield19:06:29

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.

sheluchin19:06:34

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.

seancorfield19:06:53

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?

seancorfield19:06:29

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.

sheluchin19:06:08

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.

sheluchin19:06:29

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

sheluchin19:06:51

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

sheluchin19:06:58

Yes, I have ~/.config/clojure/deps.edn, but it only has aliases in it, and I wasn't activating those.

sheluchin19:06:23

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

seancorfield19:06:48

@UPWHQK562 Can you run the -Stree command I posted above, just to check the result?

sheluchin19:06:26

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

sheluchin20:06:57

> 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

sheluchin20:06:06

> 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

sheluchin20:06:06

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

sheluchin20:06:49

I can no longer reproduce it.

Alex Miller (Clojure team)20:06:02

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

sheluchin20:06:48

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

hiredman20:06:09

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

sheluchin20:06:09

Ah yes, upgraded to 1.11.1.1149 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

hiredman20:06:48

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))
"59e68557-1a8b-48b3-97f5-1a38205ae15b"

Alex Miller (Clojure team)20:06:49

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

sheluchin20:06:36

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

sheluchin20:06:50

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

sheluchin20:06:42

And of course just the tagged literal #uuid "59e68557-1a8b-48b3-97f5-1a38205ae15b" also worked fine.

hiredman20:06:48

the difference between those identity and prn are functions, do is a special form, and and or are macros that expand to special forms

sheluchin20:06:47

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

sheluchin20:06:08

Nope, I didn't have custom readers.

sheluchin20:06:24

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

hiredman20:06:33

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

hiredman20:06:51

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

sheluchin20:06:52

I appreciate the input and insights as to potential causes. A good learning experience anyhow.

hiredman20:06:36

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)

hiredman20:06:56

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

hiredman20:06:28

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

sheluchin20:06:25

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

hiredman20:06:41

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

hiredman20:06:58

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

hiredman20:06:49

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

hiredman21:06:46

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

hiredman21:06:30

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

sheluchin21:06:35

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

sheluchin21:06:56

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

hiredman21:06:59

it is potentially very complicated, once you start adding cljs tooling to the repl (shadowcljs, piggieback) there is much more code being run there

sheluchin21:06:20

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?

hiredman21:06:58

huh, sorry, my slack seems to already be having trouble with the size of this thread, so I missed that

hiredman21:06:55

user-loaded in the output makes me deeply suspicious

hiredman21:06:44

oh, I was reading the wrong example there

hiredman21:06:33

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

hiredman21:06:52

because line 28 of https://clojurians.slack.com/files/UPWHQK562/F03MM8RAMEZ/untitled.txt?origin_team=T03RZGPFR&amp;origin_channel=Vall_threads shows the static init of the class from compiling the shadow.user namespace being run, and the error happening then

sheluchin21:06:28

Yes 😞 I will do better next time.

hiredman21:06:38

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