michael.heuberger that's unusual, how long ago did you install boot?

Is there any way for boot show -d to show the dependencies included from your profile.boot?

@kenny usually it shows them iirc

It definitely didn't for me. I kept getting classpath conflicts and realized I had been messing around with my profile.boot and left some deps in there that should not have been there.

cpmcdaniel one way is you can :exclude org.clojure/clojure from your deps

@cpmcdaniel boot show -p

And another way to is add clojure as first dep on the project

(set-env! :dependencies '[[acme/foo "1.0.0"]] :exclusions '[org.clojure/clojure]) is an example of the :exclusions way

We've actually set Clojure and ClojureScript as global exclusions so we don't have to add lots of specific exclusions on other dependencies:

(set-env! :exclusions   ['org.clojure/clojure
                         'org.clojure/clojurescript])

hmm, still shows me one of the two conflicts

the 1.2.0 one

do I need to pin my project to 1.8.0?

Boot sets the Clojure version at startup, independent of your project (which is different to Leiningen).

So that message is saying Boot is using 1.8.0 but something you're depending on from somewhere is pulling in 1.2.0.

Do you have any dependencies added via your profile.boot?

Is there a way to call a boot task with the options set in a map? e.g. (apply my-task opts).

kenny that should just work, does it not work for you?

No. I get a java.lang.ClassCastException: clojure.lang.MapEntry cannot be cast to java.lang.CharSequence with:

(core/deftask test-task
  [a apple VAL str ""]
  (println (str "I like " apply)))

(core/deftask parent-task
  []
  (apply test-task {:apple "apples"}))

(apply println {:a 1 :b 2})
  ;; [:a 1] [:b 2]
  (apply println (flatten (into '() {:a 1 :b 2})))
  ;; :a 1 :b 2

http://yellerapp.com/posts/2015-03-22-the-trouble-with-kwargs.html

and (apply println (mapcat identity {:a 1 :b 2}))

the mapcat solution is one I usually use

Ah, duh. Total brain fart. Thanks.

Is there a dynamic var, similar to *opts*, that has a set of all the allowed keywords a task can be passed?

I suppose it could be taken from the metadata on the task var.

yup - which you should be able to do inside the task body, since it gets defined and the meta added before the task would be run

Cool

Is there a way to make boot an acceptable tool for building command line tools? I’m under the impression that takes 4+ seconds on a modern machine to launch boot because it depends on clojure core. I’m curious what it would be like to extend the boot abstraction/tooling to work ontop of Node. Which might be what this probject is already trying to do. https://github.com/gfZeng/cljs-boot I really like the abstraction that boot provides and i’m guessing i would prefer it over other tools i have used in the past (Rake, Python Click) to build command line tools. But i would need it to be able launch quickly in order to be useful!

drewverlee i don't think boot can really be used for anything you want to start up quickly, because of clj startup time + pods

one distant possibility is some kind of boot-daemon/client situation but afaik nobody's worked on that much

@drewverlee I think it depends on your tolerance for "lag" time -- many of the processes I have powered by Boot take more than four seconds to run so the startup time isn't really an issue.

@drewverlee you could check out thew new clj thing, but as soon as you add bigger deps things will inevitably get slower 🙂

Thanks for the comments! I’ll need some time to understand them. Maybe i dont understand the core purpose of boot enough. The features of it that i think are applicable to building command line tools are related to the task pipelines. Which seem way more flexible and compossible then what i have seen in other languages. I suppose i saw that as the key part of boot and the “build tool, maven stuff” as things you could attach to it.

there is a correspondence between tasks that's accessible from the cli, and is high a fidelity as possible... but working at the cli repeatedly just isn't pleasant. and so most of the leverage comes with keeping a REPL open and running (boot ...) repeatedly instead of calling boot