leiningen

N.B. The maintainers are on #leiningen on Libera chat IRC. Go there for direct support/bug reports.
zendevil 2021-03-21T08:58:09.022700Z

I have a problem with accessing credentials from ~/.aws file with lein I’m using the `datomic.client.api` library, that has a function called `client` which takes in a map that contains a named profile in the `~/.aws/credentials` like so:

(client {
               :server-type :ion
               :region "us-east-1" ;; e.g. us-east-1
               :system "humboi-march-2021"
               :endpoint "<http://entry.humboi-march-2021.us-east-1.datomic.net:8182>"
               :creds-profile "humboi" ;;;;;;;;; NAMED PROFILE
               :proxy-port 8182
  })
However, when I do `lein run` or lein repl, I get the error that `profile file cannot be null`:
Syntax error (ExceptionInfo) compiling at (/private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/form-init6639201664669188954.clj:1:125).
profile file cannot be null
However, when I create an uberjar and run that, I get no such error. What might be causing this and how do I fix it?

vemv 2021-03-21T13:14:21.026100Z

getting a full stacktrace would be a good first step you can accomplish so with :jvm-opts ["-Dclojure.main.report=stderr"]

zendevil 2021-03-21T14:18:13.026300Z

@vemv this is the stacktrace:

2. Unhandled java.lang.RuntimeException
   could not start [#'humboiserver.db.core/conn] due to

                 core.cljc:   80  mount.core$up$fn__441/invoke
                 core.cljc:   80  mount.core$up/invokeStatic
                 core.cljc:   78  mount.core$up/invoke
                 core.cljc:  247  mount.core$bring/invokeStatic
                 core.cljc:  239  mount.core$bring/invoke
                 core.cljc:  289  mount.core$start/invokeStatic
                 core.cljc:  281  mount.core$start/doInvoke
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  665  clojure.core/apply
                  core.clj:  660  clojure.core/apply
                 core.cljc:  409  mount.core$start_without/invokeStatic
                 core.cljc:  403  mount.core$start_without/doInvoke
               RestFn.java:  408  clojure.lang.RestFn/invoke
                  user.clj:   19  user/start
                  user.clj:   15  user/start
                      REPL:   43  user/eval34991
                      REPL:   43  user/eval34991
             Compiler.java: 7177  clojure.lang.Compiler/eval
             Compiler.java: 7132  clojure.lang.Compiler/eval
                  core.clj: 3214  clojure.core/eval
                  core.clj: 3210  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  665  clojure.core/apply
                  core.clj: 1973  clojure.core/with-bindings*
                  core.clj: 1973  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  748  java.lang.Thread/run

1. Caused by clojure.lang.ExceptionInfo
   profile file cannot be null
   #:cognitect.anomalies{:category :cognitect.anomalies/fault,
                         :message "profile file cannot be null"}
                 async.clj:   58  datomic.client.api.async/ares
                 async.clj:   54  datomic.client.api.async/ares
                  sync.clj:   93  datomic.client.api.sync.Client/create_database
                   api.clj:  157  datomic.client.api/create-database
                   api.clj:  148  datomic.client.api/create-database
                  core.clj:   18  humboiserver.db.core/eval18401/fn
                 core.cljc:   74  mount.core$record_BANG_/invokeStatic
                 core.cljc:   73  mount.core$record_BANG_/invoke
                 core.cljc:   81  mount.core$up$fn__441/invoke
                 core.cljc:   80  mount.core$up/invokeStatic
                 core.cljc:   78  mount.core$up/invoke
                 core.cljc:  247  mount.core$bring/invokeStatic
                 core.cljc:  239  mount.core$bring/invoke
                 core.cljc:  289  mount.core$start/invokeStatic
                 core.cljc:  281  mount.core$start/doInvoke
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  665  clojure.core/apply
                  core.clj:  660  clojure.core/apply
                 core.cljc:  409  mount.core$start_without/invokeStatic
                 core.cljc:  403  mount.core$start_without/doInvoke
               RestFn.java:  408  clojure.lang.RestFn/invoke
                  user.clj:   19  user/start
                  user.clj:   15  user/start
                      REPL:   43  user/eval34991
                      REPL:   43  user/eval34991
             Compiler.java: 7177  clojure.lang.Compiler/eval
             Compiler.java: 7132  clojure.lang.Compiler/eval
                  core.clj: 3214  clojure.core/eval
                  core.clj: 3210  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  665  clojure.core/apply
                  core.clj: 1973  clojure.core/with-bindings*
                  core.clj: 1973  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  748  java.lang.Thread/run

vemv 2021-03-21T16:34:18.026600Z

sorry, nothing comes to mind. I'd double-check that ~/.aws/credentials exists, has correct syntax and that the clojure can slurp it (i.e. that there are no File permissions issues) if that fails, you might have better luck in #datomic

zendevil 2021-03-21T16:35:50.026800Z

I tried at #datomic but they say that they don’t actively use leiningen, and this seems to be a leiningen issue

vemv 2021-03-21T17:59:11.027Z

honestly it doesn't look like a Leiningen issue to me. Leiningen does not affect the set of available files for the JVM to read. the only 'special' thing it might do is setting a PWD. But it shouldn't matter because ~/.aws is not a filename relative to the PWD

quoll 2021-03-21T18:31:13.038300Z

This may just be me, but I’m encountering a new problem after I updated to Leiningen 2.9.5 recently. Some dependencies aren’t making it into the dependency tree for my projects. Say I have project A, which depends on project B, and then project B depends on an external lib C. When I build B everything works fine, and the .pom file deployed to Clojars includes the reference to C (as expected). But then when I go back to project A, it fails to build. Running lein deps :tree shows that C is missing (as if I’d excluded it). I can explicitly include a dependency on C, and it works, but I’m wondering why this is happening. The first time it happened was with a dependency on Cheshire failing to pick up part of jacksonXML. In this case, Asami depended on Zuko, which used Cheshire. Part of the dependency tree for Asami looks like this: Asami

[org.clojars.quoll/zuko "0.4.6"]
   [cheshire "5.10.0"]
     [com.fasterxml.jackson.core/jackson-core "2.10.2"]
     [com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.10.2"]
     [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.10.2"]
     [tigris "0.1.2"]
This was perfectly correct. Then I have a project which depends on Asami. The :dependency section for that project is:
:dependencies [[org.clojure/clojure "1.10.2"]
                 [org.clojure/clojurescript "1.10.773"]
                 [prismatic/schema "1.1.12"] 
                 [org.clojars.quoll/asami "2.0.0-alpha4"]
                 [aysylu/loom "1.0.2"]]
This ought to pick up everything that is in Asami, right? But it failed to run. When I looked at the deps tree, I got this:
[org.clojars.quoll/zuko "0.4.6"]
     [cheshire "5.10.0"]
       [com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.10.2"]
       [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.10.2"]
       [tigris "0.1.2"]
I’d expect this if I’d had an exclusion, but I didn’t. I got around it by adding an explicit dependency:
[com.fasterxml.jackson.core/jackson-core "2.10.2"]
It bothered me that I couldn’t see what was causing it, but it had an easy workaround, so I got back to what I was doing. But then it happened again in another project, and I had to work around it again. So I’m checking in to see if anyone else has been seeing anything like this. Or maybe I’m doing something weird and I didn’t notice when I changed it.

vemv 2021-03-24T17:47:07.039500Z

> This ought to pick up everything that is in Asami, right? But it failed to run. When I looked at the deps tree, I got this: sometimes in a the given deps :tree report, the line you're looking for might reside under some other leaf e.g. jackson deps can be scattered across the report

vemv 2021-03-24T17:48:55.039700Z

A more interesting behavior we found is that deps :tree would not render at all some items that actually are computed. I believe lein classpath never lies, whereas lein deps :tree is more of a best-effort explanation of what is being computed Feel free to ask over Webex if this sounds like a good lead :)

quoll 2021-03-25T00:18:33.040100Z

Unfortunately, it’s not. It’s (intentionally) a small dependency tree. Asami has the dependency, and uses it. Asami-Loom picks up Asami, Loom, and not much else. For some reason, it wasn’t picking up jackson-core as a transitive dependency. It wasn’t that deps :tree didn’t show it, it’s that the application wouldn’t start, since Cheshire complained. deps :tree was what revealed that jackson-core was missing. I can’t for the life of me see why. Importing it explicitly fixed it. But it SHOULD have come in transitively. Other projects using Asami were bringing it in. But this one didn’t.

👍 1
vemv 2021-03-25T00:21:12.040400Z

weird! no :managed-dependencies in play either?

quoll 2021-03-25T03:12:10.041200Z

I’m actually unaware of that option, so that’s a definite “no”