This is a follow up question to my previous asked in #C08BDAPRA channel. Now I realize that it most likely is not even boot question, more ClojureScript. But this is in the boot context. Learning boot-cljs now and I am trying to include some old good JS code. This is the snippet: https://github.com/coreasync/boot-cljs-example/commit/7707 Question: while completely arbitrary foo.bar2 is necessary to be required in "core.cljs" (as otherwise ClojureScript will not see js/foo), it seems to have no effect other than somehow making js/foo available. I guess, I am asking if this code is correct way to import JS into ClojureScript (and later Hoplon). Would appreciate a hint here.

Definitely a question for #C03S1L9DN I think...

(boot noob): Trying to run boot install on a forked project, and it fails with the following message: clojure.lang.ExceptionInfo: java.lang.Exception: can't find jar file. Tried running boot jar first. But it didn’t help. Any ideas?

This is the forked lib btw: https://github.com/andrewmcveigh/cljs-time

Nvm boot pom jar install solved it...

@vikeri: boot does not carry any state across invocations, so if you want the install task to see the jar these tasks need to be in the same pipeline/invocation.

@martinklepsch: Ok, I see. Some kind of piping

hello fellow boot users! I’m using danielsz/system and was wondering if there is a way to make boot-system stop the system cleanly on Ctrl+C. Any ideas?

ctrl-c sends a sigint right? i'm not sure if you can pre-empt the JVM's reception of the signal, which would run shutdown handlers but you cant stop the shutdown in a handler

maybe you can handle the signal in user code though, i've done that before for HUP - https://github.com/alandipert/reconfig/blob/master/src/org/dipert/reconfig.clj#L36-L43

maybe look at the reply repl client code, i think it must catch ctrl-c

at least when i have a boot repl open and i ctrl-c, it kills the current thread, not the jvm

i guess it also depends if you want system shutdown on jvm shutdown, or if this is something you want to do repetitively w/in a single jvm

if jvm, shutdown hook is the way probably

@micha: btw adding :as-jars true as an option to uber reduced the time for boot uberjar to 6 secs on osx

@esp1: interesting

although that won't produce a usable uberjar for you

but it makes sense, because there will be way fewer files to add to the jar

@esp1: what happens in incremental compile? like if you add the watch task: boot watch uberjar and you change the clojure namespace?

is the second compile fast?

it's like < 2s on my machine

that should not be doing a lot of writing to the jar, it should update the jar in place

yeah incremental is much better. i removed the :as-jars option and the initial uberjar takes > 1min, but incremental ones take 6-8 secs

one other q: i’m trying to set the target path using the -t boot option, but if i do e.g. boot -t foo target it writes to the default target directory instead of foo. this is with boot 2.6.0

am i misunderstanding how to use this option or does it simply not work? boot -e target-path=foo target also doesn’t work in the same way

hm, looks like it just doesn’t work. the target task has this binding, which has a hardcoded default that doesn’t consider cli args or anything (let [dir (or (seq dir) ["target”]). maybe the -t option should be removed from the cli? it’s kind of misleading to have it there

@esp1: good catch, thanks, can you make an issue for that please?

sure

is the desired behavior to make it work again? or to remove it?

remove it, i think

the target stuff should really be a separate task

originally we had boot automatically writing files to a target dir

just because that's how all build tools do it, we didn't really consider the implications

should the :target-path entry in the environment be removed too then?

yep, i believe so

How do I deploy my ClojureScript frontend with the rest of my Clojure app to Heroku via CircleCI? Do I use boot for this, or do I need to use Leiningen on Heroku? I presume I’ll need to make changes to circle.yml.

@petrus I think you need to bundle everything into a jar

and serve frontend files from ring handler

https://github.com/Deraen/saapas/blob/master/src/clj/backend/server.clj#L14-L15

@petrus have you tried the boot buildpack https://github.com/upworthy/heroku-buildpack-boot

Has anyone seen boot repl hang when defining a data_readers.clj file?

if I remove the file it starts normally

nope, here never seen that

it seems that it only happens if I define a data reader that another project already declares

I thought I could replace it by my own

@petrus: @jyriand: If the heroku app is to only serve frontend, there are lighter solutions which don't require starting JVM etc.

Also, I don't think Heroku is the best place to serve static files from

Does anyone have an example of a build that does subprojects within a master project? I’m writing a library that has sample applications. I want to build them all at once with the same deps & env.

@mtnygard: here is a sort of rudimentary example: https://github.com/micha/multi-module-build

that's running boot in boot

@richiardiandrea has done more sophisticated work with that

very interesting

the basic idea is that all subprojects share the build.boot with the main project

you just make a task for each subproject

then you can use the low-level boot.App api to start new instances of boot inside of boot

Boot-less has one approach which works without boot-in-boot: https://github.com/Deraen/less4clj/blob/master/build.boot

@juhoteperi: interesting approach

@juhoteperi: does that approach have limitations?

@mtnygard: Not that I can think of, but have tried to use it with different kind of projects (lib + boot + lein packages is kind of special case)

it does require filtering files using regex or something for jars

or maybe fileset metadata in some cases?

IIRC there is no currently good way to add metadata, other than selecting files using regex, which is not any better solution

It would be useful if files knew their original source-path, then that could be used

each package could have separate source-path

you could use metadata for that

annotate all the files in the fileset with where they came from

i guess the boot-in-boot approach has the advantage that different submodules can have different dependencies etc

because they share nothing

not sure if that's really an advantage in most cases though

Thanks @micha and @juhoteperi. I’m up and running.

@mtnygard: great, what did you end up doing?

Boot-in-boot. I want to build my samples under a few different Clojure versions, so the isolation helps.

cool, good luck 🙂