leiningen

jumar 2022-01-12T15:10:30.007800Z

I upgraded leiningen today to 2.9.8 (not sure what I had before, some 2.9.x) and suddenly one of my projects started failing when running lein repl

Caused by: java.lang.IllegalAccessError: resolve-var does not exist
...
    at clojure.tools.analyzer.jvm$eval68270$loading__6721__auto____68271.invoke(jvm.clj:9)
I found a very similar issue here resolve-var does not existhttps://github.com/cloojure/tupelo/issues/11 But we don't use tupelo. lein clean didn't help Any ideas about what may be wrong?

vemv 2022-01-12T15:12:14.008500Z

@jumar not sure if it's the same issue, for one thing that one is relatively old now

jumar 2022-01-12T15:12:48.009200Z

Yeah, just the symptom is very similar. The cause is likely very different

🙂 1
vemv 2022-01-12T15:12:29.008900Z

mind to post your stracktrace, full?

jumar 2022-01-12T15:13:02.009600Z

It's closed source by let me try...

vemv 2022-01-12T15:13:00.009500Z

clojure.tools.analyzer.jvm seems weird to have in Leiningen itself

jumar 2022-01-12T15:19:54.009900Z

Here's the full stacktrace with several references to propriatery namespaces replaced with things like XXX, etc.

jumar 2022-01-12T15:21:50.010500Z

Huh, it seems it's actually cider causing this - I will take it over to #cider

vemv 2022-01-12T15:29:35.010700Z

ok

zendevil.eth 2022-01-12T19:10:08.011300Z

Hi I’m getting the following error when running `lein run`. Not sure what’s causing it:

Syntax error compiling at (/tmp/form-init5805669980636889423.clj:1:73).
19
could not find a non empty configuration file to load. looked in the classpath (as a "resource") and on a file system via "conf" system property
21
This error occurs in continuous integration and not locally

vemv 2022-01-12T19:57:08.013200Z

http://grep.app hints it has to do with https://github.com/tolitius/cprop not lein itself I guess that a config file has to be present in the classpath? Make sure that's the case. lein profiles play a role, the dev profile is active by default in some but not all tasks

zendevil.eth 2022-01-12T22:47:56.013600Z

fixed

zendevil.eth 2022-01-12T22:49:29.015400Z

I’m running the following command in continuous integration: lein run -m user < /dev/null && npm i however, the problem is that the first command never terminates, and adding & after it causes the second command to run before the first command is finished. Is there a way to run the first command and wait for it to finish before running the second command?

2022-01-12T22:54:07.016300Z

that's what ; does - lein run -m user < /dev/null; npm 1 - or you can just put each command on its own line if this is a script file

2022-01-12T22:55:19.016900Z

but I'm still confused "the first command never terminates" would be a problem no matter what

dpsutton 2022-01-12T22:56:49.017700Z

if you’re starting a web server like i’ve seen you say, i would not expect lein run to terminate. It would launch a web server to keep handling requests

zendevil.eth 2022-01-12T22:57:11.018100Z

yeah but it runs a bunch of things and then settles down.

zendevil.eth 2022-01-12T22:57:29.018600Z

I want the other stuff to run (some tests) after it has populated the db in lein run and such

dpsutton 2022-01-12T23:09:06.019900Z

a straight forward way to do this is a little program that looks like

(db/migrate!)
(webserver/start! (config/CI))
(clojure.test/run-all-tests)
or something like that.

2022-01-12T23:17:35.020500Z

if the timing is predictable you can use lein run; sleep 10; npm 1

2022-01-12T23:21:27.022900Z

or you could pipe lein's output to a file, then wait for the file to contain a line of output indicating the server started before doing the next step- something like

lein run > logfile < /dev/null
tail -f logfile | grep -m1 "webserver started"
npm 1
the m1 makes grep exit after 1 match

dpsutton 2022-01-12T23:21:54.023200Z

that’s largely how nrepl works with clients

2022-01-12T23:26:25.024400Z

also, in CI you might already be dealing with docker images, and docker-compose has utilities for ensuring one task is done / ready for input before the next runs

2022-01-12T23:32:49.025600Z

another consideration is that if you make migrate a separate task instead of bundling it into run, you can wait for it to successfully complete and the start time for run will be smaller and more predictable

2022-01-12T23:33:40.026200Z

even more so, if you bulld a jar first, then use java to run that jar for the migrate and run steps