Fork me on GitHub
#boot
<
2017-08-23
>
alandipert04:08:59

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

kenny17:08:26

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

richiardiandrea17:08:58

@kenny usually it shows them iirc

kenny17:08:49

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.

alandipert17:08:09

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

kenny17:08:28

@cpmcdaniel boot show -p

juhoteperi17:08:10

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

alandipert17:08:19

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

seancorfield17:08:47

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

cpmcdaniel17:08:25

hmm, still shows me one of the two conflicts

cpmcdaniel17:08:37

the 1.2.0 one

cpmcdaniel17:08:02

do I need to pin my project to 1.8.0?

seancorfield17:08:28

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

seancorfield17:08:04

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.

seancorfield17:08:20

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

cpmcdaniel20:08:43

that was it. Thanks!

kenny17:08:10

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

alandipert18:08:51

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

kenny18:08:07

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"}))

juhoteperi18:08:07

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

juhoteperi18:08:00

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

juhoteperi18:08:09

the mapcat solution is one I usually use

kenny18:08:22

Ah, duh. Total brain fart. Thanks.

kenny18:08:57

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

kenny18:08:05

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

alandipert18:08:33

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

drewverlee18:08:44

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!

alandipert20:08:30

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

drewverlee12:08:00

Thanks alan, It looks like my idea was a candidate for google summer of code: http://clojure-gsoc.org//project-ideas/ I’m linking it because maybe the GSOC proposal is more clear about the idea then i was.

alandipert20:08:45

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

seancorfield20:08:58

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

martinklepsch20:08:31

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

drewverlee12:08:59

What do you mean “new clj thing”? Do you think the times would get to slow if boot abstraction was compiling to Node and using Node libs?

drewverlee21:08:10

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.

alandipert21:08:10

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