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?getting a full stacktrace would be a good first step
you can accomplish so with :jvm-opts ["-Dclojure.main.report=stderr"]
@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
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
I tried at #datomic but they say that they don’t actively use leiningen, and this seems to be a leiningen issue
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
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.> 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
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 :)
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.
weird! no :managed-dependencies in play either?
I’m actually unaware of that option, so that’s a definite “no”