hey guys, if I wanted to read a build.boot file and extract task options what would be the easiest way? I guess I could use some magic from boot.core namespace?

michal task options are set as metadata on the task functions, so one way woudl be to load/eval and then inspect metadata

I’ve spent the afternoon tracking down a dependency conflict inside the s3-wagon-private project, caused by different versions of jackson.core and jackson.databind in the pom.xml. However, I was still getting the same errors using the patched s3-wagon-private when trying to deploy using boot push! Eventually I discovered that push runs code in the worker pod, which is pulling in jackson transitively via an old version of cheshire. 😖

Examining the boot/worker deps tree, I’m pretty sure that bumping cheshire to 5.6 will fix this problem.

It would be great if I could get this into 2.8.0-SNAPSHOT asap. Is there any reason why cheshire in boot/worker shouldn’t be upgraded? Happy to create an issue/PR if that would help move this along.

@lsnape those Jackson dependencies are diabolical

You can say that again! If we can get Jackson above 2.6 in the worker deps, things should hopefully be a bit smoother.

Hi! Anyone successfully using https://github.com/seancorfield/boot-tools-deps with cider? While I've gotten (deps) to work with other tasks, but not with cider-jack-in.

@grzm When you cider-jack-in are you able to add the deps task to the boot command it offers you? (or does it not offer a command to update?)

There's a cider-boot-parameters variable that allows me to modify the boot args. The default (I believe) is repl -s -H :: wait. I've updated that to deps repl -s -H :: wait and can see that those are the args getting called by cider. However, the resulting classpath doesn't reflect the project deps: it's just showing the base "/Users/grzm/homebrew/bin/boot".

@dominicm in #cider is recommending calling load-deps at the top of my build.boot.

Odd... I would have expected it to run boot in the project directory (and therefore find the deps.edn file). Add the -v option to deps and see what output you get -- that should give some more insight.

(That was my lazy approach to work around this)

That will tell you which deps.edn files it is looking for...

@dominicm how many of the keys are you supplying to load-deps?

I’ve created a PR for the s3-wagon-private deps conflict issue I described above: https://github.com/boot-clj/boot/pull/679