This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-10
Channels
- # announcements (9)
- # aws (11)
- # babashka (37)
- # beginners (97)
- # biff (2)
- # calva (73)
- # clj-kondo (17)
- # cljfx (3)
- # clojure (89)
- # clojure-europe (45)
- # clojure-norway (12)
- # clojurescript (17)
- # datahike (8)
- # datomic (13)
- # deps-new (4)
- # figwheel-main (1)
- # graalvm (2)
- # hyperfiddle (8)
- # introduce-yourself (6)
- # leiningen (38)
- # lsp (57)
- # malli (13)
- # nbb (46)
- # off-topic (40)
- # pathom (3)
- # polylith (8)
- # rum (4)
- # shadow-cljs (14)
- # spacemacs (1)
- # sql (11)
- # xtdb (10)
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?
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.
do you mean it's pulling the user.clj from a dependency such as [medley "1.4.0"]
?
(totally fictional example)
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'.
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.
> 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
It should not be packaged because it's in the source path defined only in dev profile Again, it all worked in2.9.8
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?
so that's different from lein uberjar
wdyt of updating that command to lein with-profile -dev install
?
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.
And I didn't see it mentioned here: https://github.com/technomancy/leiningen/releases
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
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
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.
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
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
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
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?
are you using a plugin like lein-sub, lein-monolith? (those would be some valid answers)
I have lein-sub and am trying the following and have the error
could you post the entire stacktrace? until the very bottom (sometimes it's N stacktraces)
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)
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)
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
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
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?
Also, @U066J7E2U does this lein-sub issue look familiar?
I will create a dummy project
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
@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
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
!
Thanks for your help. I think the issue here is related to sub and not eastwood.