def is cool if boot is the entrypoint for your app at runtime

the version.txt approach is cool if boot isn't around at runtime, for ie servlets or standalone jars

real ultimate power is generating a file based on a def and adding it to the fileset at build time

@alandipert I don't see how boot's presence would affect my example 🙂 (probably because my example isn't clear on files). project-version is def'ed in core.clj so it'd be around at runtime.

someone's had an organized think about this and come up with this: https://github.com/degree9/boot-semver

is it possible to add dependencies to a project with boot ala 'npm install foo --save' ?

@macrobartfast that command modified package.json in the current project?

*modifies

yes

it grabs it and also saves it to the current project

you could accomplish this with boot, and there may be tasks out there that do such a thing

I'm using lein, and currently tediously copy each dep out clojars and paste it into project.clj

super annoying

the usual way you add dependencies is like this, in your project build.boot file:

(set-env! :dependencies #(into % '[[foo/bar "1.0"] [baz "2.0"]]))

but since you're just programming in clojure in build.boot you could do this instead:

(set-env! :dependencies #(into % (read-string (slurp "package.edn"))))

then it would be straightforward to make a task that updates package.edn or whtaever

adding or removing dependencies

does that make sense?

it does, and thanks!

you could also add this task in your ~/.boot/profile.boot file

that's the lein approach

there's a tool called lein plz that goes into your global lein profile

which I haven't tried

yeah i think it would be a straightforward job to make such a task

cool

probably i'd live with the set-env! boilerplate in the build.boot file

to keep things simple

i mean the second set-env! snippet above

gotcha

I have all the ingredients now

awesome 👍

😀

@micha Any reason to prefer set-env! with a function, over merge-env! with just the list of dependencies to add?

(merge-env! :dependencies '[[foo/bar "1.0"] [baz "2.0"]])
(merge-env! :dependencies (read-string (slurp "package.edn")))

@seancorfield no, i can't think of any reason to prefer one or the other

@kenny i understand your example now - :thumbsup:

Hello everyone

I have a problem and don't know if it's related to boot, boot-cljs, scrum (the lib I've just introduced) or my code that introduced it. Since my last commit (which added the lib and integrated it), the boot-cljs task is stuck with no CPU Usage. I used -vvvv to be super verbose and I noticed it's stuck after printing the CLJS options.

Environment :

boot --version
#
#Thu Apr 27 11:44:20 CEST 2017
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.1

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

Ok by dichotomy I managed to isolate that it's from my code... I rerun the task with just the scrum dependency added, of course it works. I run the boot-cljs task individually with the whole code : stuck. I run another task that calls cljs.build.api/build manually, stuck too. My code seems to create a kind of infinite loop at compile time but I can't see where, I just introduced the scrum lib that doesn't contain macros ! Only deftypes, one defprotocol and defns... AAAARGH ! 😱

What can make Clojurescript compilation get stuck silentely ?

@djebbz the clojurescript compiler also has a verbose option

also consider trying the newer boot-cljs 2.0.0 or so

Did both with no luck... 😕

It seems scrum and boot-cljs aren't friends, since its maintainer uses lein and has no problem.

I still can't get how a lib without macros can screw up the compilation process...

@roman01la maybe you have any ideas?

@djebbz with the clojurescripts :verbose compiler option you should see a lot more output like which file is currently being compiled

@djebbz did you see that?

@martinklepsch no idea, the code in Scrum is very simple :thinking_face:

@djebbz try to remove functions one by one from Scrum and see how it compiles, should help to locate the problem

@djebbz or even try to compile CLJS directly with CLJS compiler, without Boot

@roman01la I'm currently removing functions one by one. Compiling directly with CLJS compiler doesn't work too, same problem.

@djebbz did you see the compiler’s verbose output as I described?

@martinklepsch Yep, it blocks after one specific file ("Compiling /path/to/file"). I compared with our dev branch which doesn't use scrum and it works normally. I detected 2 files adjacents to the specific file when compiling the dev branch in verbose mode, but one of them doesn't even have scrum code in it.

I'm currently trying to set up a minimal repo to helpfully reproduce the bug

That would be very helpful 👍

I hope I manage to do it, I'm losing patience and hope... 😕

I'm using boot/new. Good idea ?

@martinklepsch I spawned a basic app project with boot/new. After adding clojurescript, boot-cljs, scrum and its dependencies, I issue boot cljs --help and get the following error : Classpath conflict: org.clojure/clojure version 1.7.0 already loaded, NOT loading version 1.8.0. I have no other instance of boot running (confirmed with ps -ef | grep -i boot). What's wrong ?

@djebbz you’re probably missing a boot.properties file. boot -V > boot.properties and then specify clojure 1.8 there and in your project dependencies

Oh, didn't know it was required.

it’s not requried. usually that conflict is not fatal so not sure what’s happening there

it is “recommended” though

No luck. Still the same classpath error after boot -V > boot.properties. When I set BOOT_CLOJURE_VERSION to 1.8.0 (like in my project) I get the same error/stack trace but without the message...

@djebbz add [org.clojure/clojure "1.8.0"] to your :dependecies

already there

My build.boot file :

(def project 'boot-scrum)
(def version "0.1.0-SNAPSHOT")

(set-env! :resource-paths #{"resources" "src"}
          :source-paths #{"test"}
          :dependencies '[ ;; Core
                          [org.clojure/clojure "1.8.0"]
                          [org.clojure/clojurescript "1.9.473"]

                          ;; 3rd party
                          [cljsjs/react-with-addons "15.4.2-0"]
                          [rum "0.10.8" :exclusions [cljsjs/react]]
                          [org.roman01la/scrum "2.0.0-SNAPSHOT" :exclusions [rum]]

                          ;; Boot
                          [adzerk/boot-cljs        "1.7.228-2" :scope "test"]
                          [adzerk/boot-test "RELEASE" :scope "test"]])

(deftask build
         "Build the project locally."
         []
         )

I didn't require cljs... HAHAHA

@djebbz if you now also have the BOOT_CLOJURE_VERSION set properly you should not get that version conflict issue

It was the cljs task not being required and just added to the dependencies. My bad. My first time writing build.boot file from (almost) scratch.

Continuing with bug reproduction. I hope I don't introduce other problems like this, just a waste of time

😅

@djebbz so the bug is still present even when cljs task is enabled?

I don't know, I haven't written any scrum code yet in this repo

@djebbz I’ve just created a separate channel for Scrum related issues

Nice ! I will pollute that one 😅

@martinklepsch Just so you know, I managed to recreate a mini app with boot and scrum and everything works nice. Good news for boot and scrum, bad news for me... I still haven't found the problem of stuck compilation.

I'll keep you informed tomorrow if I find the solution (or at least understand the problem)

End of work day for me. Bye !

@djebbz I’d be curious in a gist of the :verbose output of the clojurescript compiler

@djebbz also interested to see the compiler options you’re using

I’d try disabling :parallel-build first if it’s enabled

Is it possible to change the :source-paths in a task?

I have one task that re-compiles both frontend and backend parts of my app. The problem is it’s kind of slow. I was thinking if I could split it into two tasks, so if I modify a cljs file only the frontend re-compile is triggered.

@currentoor sure, I do that all the time for testing for example

https://github.com/anmonteiro/lumo/blob/master/build.boot#L36

Thanks @anmonteiro

do you have any other suggestions for speeding up reload times in a large cljs app?

not with boot-cljs

what do you use?

you can turn off :recompile-dependents in the CLJS compiler options but that might lead to weird bugs

I mean that boot-cljs can be quite slow and doesn’t support the entire spectrum of options that Figwheel supports, for instance

I still use boot-cljs though

or should I say boot-reload

it’s the combination of both

yeah i already turn off :recompile-dependents

there’s also https://github.com/boot-clj/boot-figreload but I don’t know how mature it is

i also found this https://github.com/aJchemist/boot-figwheel

figwheel is the only thing I still miss from lein 😅

I'm playing with Elm for front-end work these days. The language by itself is pretty neat (I still prefer ClojureScript, but it's always fun to try something new), but the build and reload tooling leave a lot to be desired. I've never written a non-trivial Boot task before, so perhaps this is a stupid question: Would it be possible to write a Boot task that automatically compiles all .elm files in some sub-directory of the project whenever they change, and use boot-reload (or whatever) to have the generated JavaScript code automatically reloaded in the browser? If yes, is there any existing Boot task I can look at that does something remotely similar?

haven't used elm myself, tho it looks very interesting. but in general boot can do anything. how do you compile elm, normally?

I’d figure anything that transforms files matching a pattern would be good inspiration, maybe a .sass compiler?

https://github.com/Deraen/boot-sass/blob/master/src/deraen/boot_sass.clj

lots of examples of input->transform->output at https://github.com/boot-clj/boot/wiki/Community-Tasks