Fork me on GitHub
#clojure
<
2022-08-27
>
DG00:08:39

Any namespace that I create under test/ is visible in the namespace resolving mechanism for libraries that I use. Is that a known behavior in Clojure? I tried with the following setup (perhaps it’s only for lib mentioned below): 1. Create a new project 2. Create a ns test/schema/utils.clj (no need to put anything there other than the ns def) 3. Add [metosin/ring-swagger-ui "4.3.0"] and [metosin/ring-swagger "0.26.2"] in the project dependencies (don’t think the version matters, tried with different ones) 4. (:require [ring.swagger.swagger-ui :as swagger-ui]) in your core.clj (or anywhere) and you’ll get an error because somewhere down the line some lib can’t import schema.utils I was under the impression that whatever goes in test stays in test

seancorfield01:08:46

I'm not sure I really understand what you're asking but it's all about the classpath under the hood. By default, projects run with src and sometimes resources on the classpath, but when you use a test runner you need test on the classpath.

seancorfield01:08:39

How are you starting your REPL/running your code? Things under test will only be accessible if you have test on your classpath, which usually would be via a :test alias if you're using the Clojure CLI.

DG09:08:29

That's weird because I ran it with lein repl

DG09:08:16

I'll try again and make sure I can reproduce properly since I also done some debugging through emacs which has its own conf

skylize02:08:49

metosin/ring-swagger uses the schema.utils namespace from prismatic/schema

skylize02:08:08

try another namespace name for your own code

DG19:08:48

Right, but I would expect it not to ‘care’ about anything that’s in test/ when I run lein do clean, repl

DG19:08:07

I checked again and it produces an error if I simply run lein repl, which I believe doesn’t load the :test profile. Once I comment out the (:require [ring.swagger.swagger-ui :as swagger-ui]) import the error is gone

seancorfield19:08:01

It may be to do with the profiles that lein uses for repl (I can no longer remember the details -- I haven't used lein for nearly seven years -- but perhaps one of the profiles it activates is bringing in your test code and it ends up on the classpath ahead of Malli, which is causing the error).

DG19:08:20

Oh alright. I’ll just be extra cautious with my test namespaces names from now on. Thanks for the help!

pez18:08:49

Dear Clojurians, I need some help figuring out a strange issue with Leiningen nrepl middleware injection. Here's a mini-project where shadow-cljs nrepl middleware is needed in order to start and connect to a ClojureScript REPL. https://github.com/PEZ/shadow-w-backend I get it to work if I start the REPL using clojure/`deps.edn`, but with Leiningen it fails on my machine if I inject the shadow middleware from the command line. (It works if I add the middleware configuration to project.clj.) Here's my repro steps: 1. In a terminal start the Clojure REPL, and nREPL server, with the needed dev tooling dependencies and middleware specified on the command line. 2. In another terminal make an nREPL connection to the started server and evaluate the functions needed to start and connect to the ClojureScript REPL. To test this you'll need nodejs and it starts with installing npm deps:

npm install
I'll add the command line I use for 1 and the evaluated forms for 2 in a reply to this post.

pez18:08:41

This is the command I use in 1 to start the Clojure REPL and nREPL server (bash/zsh):

lein update-in :dependencies conj '[nrepl,"1.0.0"]' -- update-in :dependencies conj '[cider/cider-nrepl,"0.28.5"]' -- update-in :plugins conj '[cider/cider-nrepl,"0.28.5"]' -- update-in '[:repl-options,:nrepl-middleware]' conj '[cider.nrepl/cider-middleware,shadow.cljs.devtools.server.nrepl/middleware]' -- repl :headless

pez18:08:53

Then for 2 I first connect to the nREPL server:

lein repl :connect
Then at the Clojure REPL prompt I evaluate:
(do (require 'shadow.cljs.devtools.server) (shadow.cljs.devtools.server/start!) (require 'shadow.cljs.devtools.api) (shadow.cljs.devtools.api/watch :app))
This yields this output:
shadow-cljs - HTTP server available at 
shadow-cljs - server version: 2.19.9 running at 
shadow-cljs - nREPL server started on port 57770
[:app] Configuring build.
[:app] Compiling ...
[:app] Build completed. (170 files, 92 compiled, 0 warnings, 4.11s)
:watching
Then I evaluate:
(do (require 'shadow.cljs.devtools.api) (shadow.cljs.devtools.api/nrepl-select :app))
This should give the following output:
To quit, type: :cljs/quit
[:selected :app]
cljs.user=> 
However, instead I get:
:missing-nrepl-middleware

pez18:08:02

This works on at least one machine (@thheller's) , but on my two machines it fails. I need some more clues as to what could be going wrong, so it would be great if you could test the repro and tell me how you fare. Thanks in advance! ❤️ 🙏

pez19:08:43

Update: So, this actually doesn't work on @thheller’s machine either, we've just concluded. There is probably little point in more people checking if it works. I've now filed an issue on Leiningen checking if my expectations are valid or not: https://codeberg.org/leiningen/leiningen/issues/10

joelkuiper18:08:03

bit of a silly question but I'm trying to pass an absolute path (e.g "/x/y/") via clj -X but I get Unreadable arg: ... is there a way around that?

joelkuiper18:08:46

could also just use env vars I guess

p-himik18:08:09

Try wrapping in extra quotes: '"/x/y/"'.

👍 1
joelkuiper18:08:12

that did the trick, thanks! had me confused for a second 😄

pez18:08:55

Sorry if you already know this, but for me it helps with quoting issues to know that it is the shell unpacking the outmost quotes, and the command gets the result of that unpacking. For double quotes the shell (assuming something bash-y) will interpolate the contained string, and for single quotes it will leave the string alone and pass it as it is. That's why those extra quotes helps here. The command (`clj` in this case) gets "/x/y/" as an argument. Whereas without the outer single quotes clj will get /x/y/.

joelkuiper18:08:34

Oh that is definitely useful information, maybe I knew this once but I definitely forgot it

🙏 1
vemv21:08:00

Leaving aside Malli specificities, what's the nature of this issue? The line in question looks like a vanilla reify implementing a defprotocol

1. Caused by java.lang.ClassNotFoundException
   malli.transform$transformer$reify__226743$fn__226750

            transform.cljc:  331  malli.transform$transformer$reify__226743/_value_transformer
                 core.cljc: 1185  malli.core$_collection_schema$reify$reify__2972/_transformer
                 core.cljc: 2117  malli.core$decoder/invokeStatic
                 core.cljc: 2112  malli.core$decoder/invoke
                 core.cljc: 2125  malli.core$decode/invokeStatic
                 core.cljc: 2120  malli.core$decode/invoke
I tried require :reload of each involved ns, to no avail. Anyway I'm most curious about why a reify class would become undefined. It doesn't look like this sort of issue (which I'm very familiar with): https://github.com/clojure/tools.namespace/tree/bd78b34d9551c99910a24ce939c2137fcf1bede1#warnings-for-protocols

hiredman21:08:11

It isn't the reify class that isn't found, it is some fn created in the reify (possibly a once fn inserted by the compiler for complex control flow)

hiredman21:08:08

The only reason that I can think of for that to be missing is aot compilation+some kind of deletion of some of the class files

hiredman21:08:48

(possibly trying to work around the transitive nature of aot compilation)

vemv21:08:43

Thanks! That sounds on the right track. I use https://clojure.org/guides/dev_startup_time (or at least a bespoke variation) It hadn't given me any issues for over a year so I forgot it was even part of my setup. So yeah probably this happens when I run the test suite from the CLI, which wipes the existing repl's cache

vemv21:08:42

Part of why it very rarely happened to me is because I use :target-path "target/%s" (Lein thing), however that wasn't setup in this foreign project