Fork me on GitHub
#leiningen
<
2022-08-10
>
jumar10:08:39

I'm facing a weird problem with new leiningen version 2.9.9. It seems to include user.clj file from one of the dependencies in the uberjar while the user.clj is only supposed to be used for the dev profile - it is not included in source paths for uberjar profile. It all worked well with 2.9.8 and we actually noticed this only after leiningen on our CI machines (github actions) got updated to 2.9.9 Any idea why is that or somebody with the same problem?

jumar10:08:33

Our problem then is, that this user.clj is automatically loaded by Clojure and since it's referring to a dev-only dependency the app fails to start in production settings.

vemv10:08:15

do you mean it's pulling the user.clj from a dependency such as [medley "1.4.0"] ? (totally fictional example)

jumar10:08:24

it's pulling user.clj from our internal lib which is set as a dependency of the project. The user.clj ends up in the uberjar's root 'folder'.

jumar10:08:43

It seems like it's activating dev profile by default.

jumar10:08:15

I'm now looking at how to downgrade leiningen to 2.9.8 on github actions runner but not sure about the best approach here. The runners come with 2.9.9 preinstalled.

vemv10:08:08

> from our internal lib which is set as a dependency of the project. what does this mean? is it a vanilla dependency? Where I want to go is: if a dependency, as a .jar, was packaged including a user.clj, that's the root cause, lein uberjar only unveils that condition

jumar10:08:39

It should not be packaged because it's in the source path defined only in dev profile Again, it all worked in2.9.8

jumar10:08:16

Could it be something with lein install activating the dev profile by default?

vemv10:08:59

I find there's a contradiction in your problem statement. Maybe it worked only by chance > It should not be packaged because it's in the source path defined only in dev profile lein uberjar uberjars other dependencies. It doesn't build those dependencies. It doesn't know anything about those project's dev profiles maybe you're using a monolithic build system via some Lein plugin?

๐Ÿ‘ 1
jumar10:08:14

During our build, we first call lein install to store the dependency in the local repo

vemv10:08:18

so that's different from lein uberjar wdyt of updating that command to lein with-profile -dev install ?

jumar11:08:50

Thanks for the suggestion - I'll try that. Nevertheless, it looks to me like a pretty serious regression in leiningen - tricky and hard to debug.

vemv12:08:27

idk For a few years I've invoked all important commands with an with-profile -dev - one never knows when that implicit profile might be activated anyway, if you can isolatedly repro that lein install started activating the dev profile, that surely would be a welcome issue report

๐Ÿ‘ 2
jumar12:08:32

Yes, I'll remember that ๐Ÿ™‚ Thanks for your help!

๐Ÿป 1
eskos13:08:49

This is a known bug in 2.9.9, as soon as it was noticed yesterday technomancy jumped on it and started fixing it. It is recommended to stay on 2.9.8 and wait until 2.9.10 if possible; the bug has been fixed, but turns out to be one of those things where fixing one bug introduces another one. Because of move to Codeberg thereโ€™s nothing on the GitHub side about this; the issue in question is being tracked here https://codeberg.org/leiningen/leiningen/issues/5 Recommended workaround is lein with-profile production uberjar

jumar14:08:42

Thanks! Indeed, I noticed that even with lein with-profile -dev install it still fails because lein uberjar run on the main project still includes user.clj from the main project - the difference is that it's AOT-compiled and fails with a different error at runtime.

vemv15:08:39

Wouldn't lein with-profile -dev uberjar fix that?

jumar15:08:22

Probably, but we were talking about lein install before.

jumar15:08:08

Also, I lean toward with-profile production if that actually works.

vemv15:08:25

well, the bug mutated :) I'd recommend to be careful with profiles for every important invocation, it's part of Lein mastery imo with-profile production deactivates other profiles (given lack of + or -) may or may not be what you want

jumar15:08:46

Yeah, I must agree with this ๐Ÿ™‚ > I'd recommend to be careful with profiles for every important invocation, it's part of Lein mastery imo

eskos13:08:49

This is a known bug in 2.9.9, as soon as it was noticed yesterday technomancy jumped on it and started fixing it. It is recommended to stay on 2.9.8 and wait until 2.9.10 if possible; the bug has been fixed, but turns out to be one of those things where fixing one bug introduces another one. Because of move to Codeberg thereโ€™s nothing on the GitHub side about this; the issue in question is being tracked here https://codeberg.org/leiningen/leiningen/issues/5 Recommended workaround is lein with-profile production uberjar

Yuner Bekir14:08:19

Hello guys! I am trying to invoke an alias in a child (sub) project which is consisted of multiple other sub projects, while running an alias from the parent project. Is there a way to do it?

vemv14:08:19

are you using a plugin like lein-sub, lein-monolith? (those would be some valid answers)

Yuner Bekir14:08:50

I have lein-sub and am trying the following and have the error

vemv15:08:59

could you post the entire stacktrace? until the very bottom (sometimes it's N stacktraces)

vemv15:08:34

a quick thing you can try is changing the command to with-profile +test eastwood I'll be back in a few hours. Would love to help (I maintain Eastwood and have solved sub issues in the past)

๐Ÿ™Œ 1
Yuner Bekir15:08:50

lein eastwood-all
Reading project from connectors
Reading project from zendesk
java.lang.Exception: Error loading zendesk/project.clj
 at leiningen.core.project$read_raw$fn__8045.invoke (project.clj:1101)
    leiningen.core.project$read_raw.invokeStatic (project.clj:1095)
    leiningen.core.project$read_raw.invoke (project.clj:1091)
    leiningen.core.project$read.invokeStatic (project.clj:1112)
    leiningen.core.project$read.invoke (project.clj:1109)
    leiningen.core.project$read.invokeStatic (project.clj:1113)
    leiningen.core.project$read.invoke (project.clj:1109)
    leiningen.sub$apply_task_to_subproject.invokeStatic (sub.clj:11)
    leiningen.sub$apply_task_to_subproject.invoke (sub.clj:7)
    leiningen.sub$sub.invokeStatic (sub.clj:51)
    leiningen.sub$sub.doInvoke (sub.clj:46)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.sub$apply_task_to_subproject.invokeStatic (sub.clj:13)
    leiningen.sub$apply_task_to_subproject.invoke (sub.clj:7)
    leiningen.sub$sub.invokeStatic (sub.clj:51)
    leiningen.sub$sub.doInvoke (sub.clj:46)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
    $do.invokeStatic (do.clj:40)
    $do.doInvoke (do.clj:32)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
    leiningen.core.main$_main$fn__7419.invoke (main.clj:453)
    leiningen.core.main$_main.invokeStatic (main.clj:442)
    leiningen.core.main$_main.doInvoke (main.clj:439)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:665)
    clojure.main$main_opt.invokeStatic (main.clj:514)
    clojure.main$main_opt.invoke (main.clj:510)
    clojure.main$main.invokeStatic (main.clj:664)
    clojure.main$main.doInvoke (main.clj:616)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.main.main (main.java:40)
Caused by: java.io.FileNotFoundException: zendesk\project.clj (The system cannot find the path specified)
 at java.io.FileInputStream.open0 (FileInputStream.java:-2)
    java.io.FileInputStream.open (FileInputStream.java:195)
    java.io.FileInputStream.<init> (FileInputStream.java:138)
    java.io.FileInputStream.<init> (FileInputStream.java:93)
    clojure.lang.Compiler.loadFile (Compiler.java:7571)
    clojure.lang.RT$3.invoke (RT.java:327)
    leiningen.core.project$read_raw$fn__8045.invoke (project.clj:1099)
    leiningen.core.project$read_raw.invokeStatic (project.clj:1095)
    leiningen.core.project$read_raw.invoke (project.clj:1091)
    leiningen.core.project$read.invokeStatic (project.clj:1112)
    leiningen.core.project$read.invoke (project.clj:1109)
    leiningen.core.project$read.invokeStatic (project.clj:1113)
    leiningen.core.project$read.invoke (project.clj:1109)
    leiningen.sub$apply_task_to_subproject.invokeStatic (sub.clj:11)
    leiningen.sub$apply_task_to_subproject.invoke (sub.clj:7)
    leiningen.sub$sub.invokeStatic (sub.clj:51)
    leiningen.sub$sub.doInvoke (sub.clj:46)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.sub$apply_task_to_subproject.invokeStatic (sub.clj:13)
    leiningen.sub$apply_task_to_subproject.invoke (sub.clj:7)
    leiningen.sub$sub.invokeStatic (sub.clj:51)
    leiningen.sub$sub.doInvoke (sub.clj:46)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
    $do.invokeStatic (do.clj:40)
    $do.doInvoke (do.clj:32)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$partial_task$fn__7330.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
    leiningen.core.main$_main$fn__7419.invoke (main.clj:453)
    leiningen.core.main$_main.invokeStatic (main.clj:442)
    leiningen.core.main$_main.doInvoke (main.clj:439)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:665)
    clojure.main$main_opt.invokeStatic (main.clj:514)
    clojure.main$main_opt.invoke (main.clj:510)
    clojure.main$main.invokeStatic (main.clj:664)
    clojure.main$main.doInvoke (main.clj:616)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.main.main (main.java:40)

vemv09:08:27

So far I have no clue :) I don't see eastwood in the stacktrace. Does the error happen with any other command? e.g. deps

Yuner Bekir15:08:41

it works fine. These are my subprojects. The connectors project contains all other projects. For some reason if I try to run lein sub eastwood it fails when I have the connectors sub project in the list, but works fine for the others

๐Ÿ‘ 1
vemv18:08:16

So as mentioned, since I see no eastwood in the stacktrace it's hard to tell what's happening -_- Could you create a repro project and report it as an issue in eastwood?

vemv18:08:42

Also, @U066J7E2U does this lein-sub issue look familiar?

Yuner Bekir06:08:05

I will create a dummy project

Yuner Bekir07:08:19

https://github.com/yunerbekir/clojure-nested-eastwood here it is. try running lein sub eastwood in the root directory and you will get an error. What I expect to happen is that it will trigger sub eastwood inside the nested project

๐Ÿ‘ 1
Shantanu Kumar11:08:37

@U01B65G1Z63 Thanks for the repro project. I am able to reproduce the error, which appears to be due to nested use of lein-sub i.e. using lein-sub in a sub-project. I will look into it soon. /cc @U45T93RA6

๐Ÿ‘ 1
๐Ÿ™Œ 1
vemv11:08:34

Thanks, I was looking at it :) that saves me much debugging time. Probably having deeply nested projects is not a best practice anyway. Also, these days Eastwood latest is 1.2.4 !

Yuner Bekir11:08:40

Thanks for your help. I think the issue here is related to sub and not eastwood.