I think I had something working but accidentally rm’ed it (I know.. -_-)… But.. I’m trying to replace a task (using replace-task!) and specify the task options for the new task:

(replace-task!
  [task test-cljs]
  (fn [o once? bool "run tests once and exit"]
    (comp (if once? identity (watch))
          (task :exit? (not once?) :optimizations :none))))

Hi, I have a problem with boot watch build, the execution of jar starts failing after second rebuild, I described it here: http://stackoverflow.com/questions/40739803/boot-clj-watch-build-run-jar-ok-change-code-run-jar-fail-could-not

When you get a warning like Warning: version conflict detected: org.clojure/clojure version changes from 1.9.0-alpha14 to 1.7.0, am I correct in interpreting that as the classpath of the current pod being changed to downgrade a dependency? And if that is the case, are there any generic hints on where to start looking to figure out why this is happening?

@grant this happens when one version of a dependency is already on the classpath when another version of it is added to the classpath, too

it is something you want to avoid doing, so there is a warning

but there isn't a good way to handle it automatically

it usually happens when you add dependencies in multiple separate calls to set-env!

this is related to the way maven automatic dependency conflict resolution is implemented

maven collects all of your :dependnecies and builds a graph inclusing dependencies of your dependencies (transitive deps)

then, if there are conflicts, like say dependency X version 1 is needed by dependency A, but X version 2 is needed by dependency B

(and X is not one of your specified dependencies, so you have not specified a specific version of it)

in that case maven will choose the version of X that is needed by the dependency that is the closest to your own dependencies in the transitive dependency chain

or in other words it chooses the version of the transitive dependency X that is at the least depth in the dependency tree

but this really only works well when you let maven resolve conflicts all in one shot

maven needs to know all of your dependencies for this resolution strategy to work

when you make two separate set-env! calls, the second one is at a disadvantage

if the first call knew about the other dependencies you would have added, it would perhaps have chosen a different version of some transitive dependencies

does that make sense?

oh an important fact to know is that dependencies cannot be removed from the classpath

so it can't uninstall the version that's already on the classpath

and install a different version

Ah, so my bug is calling set-env with just the added dependency. I need to conj onto the current set of deps instead. Or build a whole new pod.

a new pod is the best way

but the warning may be benign

you can also use :exclusions

well so given the problem outlined above, there are a few standard ways of handling dependency conflicts like this

As a general rule, I try not to just disregard warning, especially if I'm not 100% sure I understand exactly what is going on. 🙂

the first way is to add an explicit dependency to the second set-env! call

with the version that was already loaded

that will instruct maven to use that specific version in its calculations, overriding the transitive version

the second way is to add an :exclusions to the dependency coordinates of the second set-env! call

(set-env! :dependencies #(conj % '[foo/bar "1.2.3" :exclusions [some/dependency]]))

the third way is to make a new pod:

In my particular case, I am wanting a task that reformats code, but the cljfmt library is just a dependency of the task, not the application, so didn't want to include that dependency in the main set-env.

a pod is perfect for that

That is what it was seeming like to me.

(def p
  (make-pod
    (update-in boot.pod/env
      [:dependencies] conj '[foo/bar "1.2.3"])))

you can use all the boot show -d and boot show -p etc to inspect the pod you make, too

they take a --pods option to allow you to select your pod by name

so if you want to see the dependecy tree in your pod or something you can do that

Ah, cool, always easier to understand what's going on when you can see it.

👍

As always, thanks for all the help Micha.

sure anytime 🙂

welcome to the pod, cozy in here

@micha I figured it would be obvious on the wiki, but I'm not finding it, what is the recommend way to make a task run in its own pod?

Hi Alan.

the general pattern is not to run the whole task in the pod, but the parts of its impl. that depend on the dep

i will try to find an example

Ah, so use with-call-in

or if your with-call-in code gets uncomfortably large, you can move the code you want to run in the pod to another namespace, usually called impl.clj or something

then in with-call-in, you require it and do stuff

usually the thing your task does is related to files, so the value you pass across the pod membrane is a path as a string, the directory where the files to do work on are

https://github.com/adzerk-oss/boot-template/blob/master/src/adzerk/boot_template.clj is an example

Gotcha. Makes sense I think. I know in a few minutes when it works. 🙂

:thumbsup:

oh i forgot, with-eval-in vs with-call-in. eval-in takes code, call-in takes a namespace-qualified symbol

so usually one graduates from with-eval-in to with-call-in

well they're for different purposes

Ah, eval may be the way to go then, for now.

with-call-in needs to be passed java objects as arguments

with-eval-in uses the clojure printer and reader to ship expressions and results between pods

if you need to do something involving data that can't be round tripped through the reader/printer then you would need to use with-call-in

because each pod has its own isolated clojure runtime

including all the protocols and so on

so a clojure map in one pod is just an unknown java object in another pod

and none of the protocols in the second pod are implemented on the object passed to it from the first pod

I can see how that would get confusing if you forgot to keep that in mind.

> · A weird imagination is most useful to gain full advantage of all the features.

(from man screen, also true of boot)

Howdy! As a misguided public service, I'm actively looking for clojure projects that don't work under Java 9. I know of a couple in Boot - is someone already looking at those? If not, I can rake up a pile of PRs

https://github.com/boot-clj/boot/issues/525 is one, but I know boot.pods will puke on dynapath once we get past that one

s/PRs/issues/, more likely

@tcrawley sweet! yeah, probably should start getting things ready for java 9 eh?

you have until July (or later, if the schedule slips again), but I'm trying to make sure we're not all caught with our pants down

I'm using https://github.com/tobias/clojure-java-9/issues as a central point to track issues

how do you feel about the modules jigsaw stuff?

meh

think it's going to be useful?

well, I haven't looked at it beyond "this breaks clojure"

once things get stable there, I'll look at how useful modules actually are

oh i didn't know it interferes with clojure

clojure itself has one issue with reflection (http://dev.clojure.org/jira/browse/CLJ-2066), and lein and boot won't be able to load from the bootclasspath any longer (I'll file a boot issue for that in the next few minutes)

Hey Bootonnieres! I am trying to get started with Boot by converting a pretty simple leiningen app, but any commanding is giving me this error:

clojure.lang.ExceptionInfo: org.clojure data: {:file "/var/folders/4d/ylhwc8zs44x2g6z9s3wf32hc0000gp/T/boot.user9194257774879762845.clj", :line 5} java.lang.ClassNotFoundException: org.clojure ... boot.main/-main/fn main.clj: 196 boot.main/-main main.clj: 196 ... boot.App.runBoot App.java: 399 boot.App.main App.java: 488 ... Boot.main Boot.java: 258

@monjohn can you paste the build.boot file you're using?

looks like you need to quote the dependencies?

or is the paste swallowing the single quote

(set-env!
  ...
  :dependencies '[[...

set-env! is a function, it's not a macro

so its arguments will be evaluated

and org.clojure/clojure isn't a var

that's why you get that error

@micha That did it! I really thought that I had fixed that before. But I guess I hadn’t. Thanks!

👍