Fork me on GitHub
#boot
<
2016-09-23
>
donaldball00:09:08

Okay, so I’m now trying to load a wagon from a non-standard public maven

donaldball00:09:34

Leiningen seems to offer a :plugin-repositories to allow for this; does boot have something similar?

donaldball02:09:32

Well, I went ahead and forked aws-maven, updated the dependencies, everything seems fine in my gross testing at a repl in that project

donaldball02:09:56

Unfortunately, when I try to use it to resolve a dependency in boot, I get:

donaldball03:09:39

java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.JavaType.isReferenceType()Z

donaldball03:09:15

Which implies a version conflict in jackson. I haven’t declared a jackson version, amazonaws is in charge of that, and boot -BPd boot/aether -d sparkfund/aws-maven:5.1.0 show -d shows the jackson versions I expect, that worked in the aws-maven repl

alandipert03:09:29

@donaldball it's possible something was compiled against a version of jackson that isn't around, which isn't exactly a version conflict

alandipert03:09:02

an s3 wagon that loaded the aws stuff it needed in a pod would be ideal

donaldball03:09:33

It very much looks like the jackon that’s available when I run e.g. boot repl when the dependency resolver runs is < jackson 2.6.0

donaldball03:09:51

I would be delighted to explore the wagon in a pod notion

alandipert03:09:46

it would be a bit of a mission... but if it's something you're interested in exploring, the idea would be to just use a pod everywhere it calls aws stuff

alandipert03:09:09

would probably create an impl class that proxies all the necessay calls to s3 world in a pod

donaldball03:09:57

That seems like the most promising long-term solution

alandipert03:09:18

trying out your build.boot here

alandipert03:09:46

my theory is that the wagon runs in the "worker pod" which is where all the deps that support boot tasks live

alandipert03:09:55

and that cheshire (and jackson) are already in there

donaldball03:09:08

Alternately, I could see if I can find a version of amazon that works with temporary credentials and the version of cheshire/jackson that the boot worker pod uses

alandipert03:09:32

that could work

alandipert03:09:37

looks like the jackson in there is 2.3.1

alandipert03:09:35

what do you mean by working with temporary credentials?

donaldball03:09:02

We use aws-vault to issue temporary amazon credentials using the STS service. For some inexplicable reason, these credentials don’t work in older versions of the amazon java library.

donaldball03:09:34

It makes it v easy and safe to assume specific roles for short durations

alandipert03:09:38

could you resolve them in a new version of aws running in a pod, get the id/key strings, and then configure the working s3 wagon using them?

alandipert03:09:06

afaik the amazon cred resolution stuff boils down to 2 strings always

donaldball03:09:49

yeah, but the sts strings just flat out aren’t accepted in the old libs. It’s mind-boggling, but

alandipert03:09:09

that is a bummer

donaldball03:09:53

Yeah, well. Thanks for the pod suggestion, and for confirming that the dependency resolution worker pod is the source of this jackson conflict.

alandipert03:09:05

well, i haven't confirmed, just my best guess

alandipert03:09:21

will be around tomorrow though to rap more

donaldball03:09:48

(I checked, it provides jackson 2.3.1)

alandipert03:09:23

the right thing might be for boot to run the aether stuff in a pod separate from worker

alandipert03:09:55

or maybe for boot to run all wagons in their own pods, and then put the shim in boot itself

alandipert03:09:16

downside could be startup time tho

donaldball03:09:45

Oh, thank heavens. I found a version of amazonaws that’s old enough to work with boot’s cheshire, but new enough to support STS credentials.

alandipert03:09:57

ewok_celebration.mp3

donaldball03:09:55

Agree that worker isolation would be laudable, or at least a nice thing to be able to easily control

donaldball03:09:23

And thanks very much for your help in the diagnosis

grounded_sage05:09:18

I'm a bit stumped. Just going through the boot Modern-CLJS tutorial https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-01.md About half way down the first time I run

boot-cljs
it doesn't spit out the files is says it should.

grounded_sage05:09:29

It says it compiles main.js but I don't see it anywhere

Writing main.cljs.edn...
Compiling ClojureScript...
• main.js

grounded_sage05:09:55

Ok I went a bit further on and it seems the tutorial is slightly out of date as Target directories are not implied anymore

borkdude15:09:53

We are using boot and have (enable-console-print!) in a main cljs file that we only load in dev. But println doesn’t seem to work when namespaces are reloaded. Is this a familiar issue?

eggsyntax15:09:18

Looks like *print-namespace-maps* can't be set in the boot repl. Any way around that that y'all know of? Or are there any plans for a boot release that's *print-namespace-maps*-aware?

db.seed.create-specs> (set! *print-namespace-maps* false)
false
db.seed.create-specs> (println *print-namespace-maps*)
true
Fuller description, with clarification from Alex Miller that it's a matter of the specific repl, in #clojure: https://clojurians.slack.com/archives/clojure/p1474637182004369

micha15:09:14

@eggsyntax you can make nrepl middleware to do it maybe?

micha15:09:30

the boot repl task allows you to add middleware

eggsyntax15:09:50

Seems plausible. Can't tackle that any time soon, but I may if someone else doesn't get to it first.

Alex Miller (Clojure team)16:09:34

@eggsyntax I’m curious why it would be true at all - if using the latest Clojure, it should be false by default if you’re not using the main clojure.repl

eggsyntax16:09:13

I'm using the boot repl via CIDER.

micha16:09:31

ah yes, it could be a CIDER setting?

eggsyntax16:09:50

Hmm, I wonder, I'll dig into that a bit.

micha16:09:03

which version of clojure are you using?

micha16:09:08

i can do a quick test here

eggsyntax16:09:37

Should have mentioned that it's a new var as of that release.

Alex Miller (Clojure team)16:09:26

(it was added in alpha11 actually)

eggsyntax16:09:35

Doesn't look like CIDER takes it into account at all.

eggsyntax16:09:39

Not surprising, since it's so new. I'm guessing CIDER just honors whatever the underlying repl does.

Alex Miller (Clojure team)16:09:03

some of the repls re-use the clojure.main/with-bindings function where this is set, but I have not followed which closely

Alex Miller (Clojure team)16:09:30

but that function exists so could certainly be reused to stay in sync

eggsyntax16:09:43

Behavior's the same in a vanilla CLI boot repl:

user=> *print-namespace-maps*
true
user=> (set! *print-namespace-maps* false)
false
user=> *print-namespace-maps*
true

Alex Miller (Clojure team)16:09:22

I don’t get how it starts as true unless it’s using with-bindings - that’s the only thing that sets that to true in Clojure core

Alex Miller (Clojure team)16:09:50

but maybe across the client/server split the server is not eval’ing in the context of the bindings set on the client

micha16:09:53

@eggsyntax are you adding nrepl to your dependencies? maybe transitively?

micha16:09:13

can you look in boot show -d to verify?

Alex Miller (Clojure team)16:09:23

the Clojure socket server repl reuses clojure.main’s repl so supports this automatically

eggsyntax16:09:13

Only in test. [org.clojure/tools.nrepl "0.2.12" :scope "test"]

Alex Miller (Clojure team)16:09:42

clojure.tools.nrepl.middleware.session/create-session does use with-bindings

eggsyntax16:09:56

Changing the nrepl dependency to be in all scopes doesn't change the behavior (not sure whether y'all were suggesting it would -- my knowledge of the underlying repl mechanics is pretty slim).

esp116:09:24

i don’t think this has anything to do with nrepl:

12:13 $ BOOT_CLOJURE_VERSION=1.9.0-alpha12 boot show -d
[boot-deps "0.1.6"]
✔ ~
12:13 $ BOOT_CLOJURE_VERSION=1.9.0-alpha12 boot repl
nREPL server started on port 57185 on host 127.0.0.1 - 
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0-alpha12
Java HotSpot(TM) 64-Bit Server VM 1.8.0_102-b14
        Exit: Control+D or (exit) or (quit)
    Commands: (user/help)
        Docs: (doc function-name-here)
              (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
      Source: (source function-name-here)
     Javadoc: (javadoc java-object-or-class-here)
    Examples from : [clojuredocs or cdoc]
              (user/clojuredocs name-here)
              (user/clojuredocs "ns-here" "name-here")
boot.user=> *print-namespace-maps*
true
boot.user=> (set! *print-namespace-maps* false)
false
boot.user=> *print-namespace-maps*
true
boot.user=>

micha16:09:06

i can't really follow the flow there though

esp116:09:03

oh hm. could this be at all related w/prev issue of *data-readers* not being available in the boot repl?

micha16:09:32

the link i pasted above was the place where we fixed that

micha16:09:00

it's a little tricky with this one because we need to not break when clojure doesn't have the var

eggsyntax16:09:21

Gotta run for about an hour, I'll check back later (although I probably won't have much to contribute on this one). Thanks for taking a look, y'all!

micha16:09:45

@eggsyntax i can push a fix to master in a bit

micha16:09:59

at least to workaround pending a better fix

esp116:09:48

so this is interesting. this happens on a fresh boot repl before trying to change the binding of *print-namespace-maps* at all:

boot.user=> *print-namespace-maps*
true
boot.user=> (.getRawRoot #'*print-namespace-maps*)
false

eggsyntax17:09:05

@micha that’s awesome, many thanks 🙂