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

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

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

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

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

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

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

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

https://gist.github.com/dball/d295118c35c12e5d148b79bda761db98 is the simplest boot script that fails

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

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

looking at https://github.com/technomancy/s3-wagon-private/blob/master/src/main/java/org/springframework/build/aws/maven/PrivateS3Wagon.java

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

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

That seems like the most promising long-term solution

trying out your build.boot here

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

and that cheshire (and jackson) are already in there

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

that could work

looks like the jackson in there is 2.3.1

what do you mean by working with temporary credentials?

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.

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

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?

alas

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

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

¯\(ツ)/¯

oic

that is a bummer

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

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

will be around tomorrow though to rap more

(I checked, it provides jackson 2.3.1)

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

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

downside could be startup time tho

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.

\o/

ewok_celebration.mp3

:jub-jub:

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

And thanks very much for your help in the diagnosis

no prob

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 says it compiles main.js but I don't see it anywhere

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

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

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?

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

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

the boot repl task allows you to add middleware

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

@eggsyntax this could be a good place to add this kind of setting: https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/repl_server.clj#L17-L35

@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

I'm using the boot repl via CIDER.

ah yes, it could be a CIDER setting?

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

which version of clojure are you using?

i can do a quick test here

1.9-alpha12

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

(it was added in alpha11 actually)

Ah, my bad.

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

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

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

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

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

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

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

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

can you look in boot show -d to verify?

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

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

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

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).

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=>

i suspect that nrepl is doing something: https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L68-L69

i can't really follow the flow there though

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

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

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

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!

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

at least to workaround pending a better fix

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

@micha that’s awesome, many thanks 🙂