Fork me on GitHub
#boot
<
2016-06-30
>
Andy04:06:54

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.

seancorfield05:06:42

Definitely a question for #C03S1L9DN I think...

vikeri06:06:18

(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?

vikeri06:06:36

Nvm boot pom jar install solved it...

martinklepsch07:06:30

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

vikeri10:06:15

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

msuess12:06:11

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?

alandipert13:06:42

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

alandipert13:06:07

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

alandipert13:06:38

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

alandipert13:06:55

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

alandipert13:06:30

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

alandipert13:06:49

if jvm, shutdown hook is the way probably

esp115:06:08

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

micha15:06:14

@esp1: interesting

micha15:06:24

although that won't produce a usable uberjar for you

micha15:06:47

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

micha15:06:10

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

micha15:06:23

is the second compile fast?

micha15:06:29

it's like < 2s on my machine

micha15:06:49

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

esp115:06:07

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

esp115:06:04

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

esp115:06:47

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

esp115:06:49

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

micha15:06:32

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

esp115:06:01

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

micha15:06:07

remove it, i think

micha15:06:23

the target stuff should really be a separate task

micha15:06:43

originally we had boot automatically writing files to a target dir

micha15:06:02

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

esp115:06:30

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

micha15:06:46

yep, i believe so

braai engineer16:06:24

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.

jyriand16:06:43

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

jyriand16:06:40

and serve frontend files from ring handler

anmonteiro18:06:07

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

anmonteiro18:06:29

if I remove the file it starts normally

richiardiandrea18:06:00

nope, here never seen that

anmonteiro18:06:05

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

anmonteiro18:06:19

I thought I could replace it by my own

juhoteperi18:06:05

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

juhoteperi18:06:03

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

mtnygard20:06:34

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.

micha20:06:28

that's running boot in boot

micha20:06:55

@richiardiandrea has done more sophisticated work with that

mtnygard20:06:58

very interesting

micha20:06:00

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

micha20:06:10

you just make a task for each subproject

micha20:06:40

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

juhoteperi20:06:57

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

micha20:06:05

@juhoteperi: interesting approach

mtnygard20:06:07

@juhoteperi: does that approach have limitations?

juhoteperi20:06:43

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

juhoteperi20:06:59

it does require filtering files using regex or something for jars

micha20:06:29

or maybe fileset metadata in some cases?

juhoteperi20:06:12

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

juhoteperi20:06:20

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

juhoteperi20:06:29

each package could have separate source-path

micha20:06:45

you could use metadata for that

micha20:06:05

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

micha20:06:17

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

micha20:06:23

because they share nothing

micha20:06:40

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

mtnygard20:06:28

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

micha20:06:58

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

mtnygard20:06:26

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

micha20:06:46

cool, good luck 🙂