Fork me on GitHub
#boot
<
2017-07-06
>
minikomi04:07:56

I created a task which processes some images.. I was under the impression that if I keep the tmp-dir around between runs of the task and boot/add-resource each time, the previously created files would be added.. a mistake?

minikomi05:07:42

nevermind, user error.

dominicm08:07:43

@mpenet https://github.com/clojure-emacs/cider/pull/2027 use .dir-locals.el again 🙂 no more security warning (do an update ofc)

donyorm09:07:35

So am I right that boot-figreload (https://github.com/boot-clj/boot-figreload) is the currently perferred alternative to lein-fighweel for boot?

dominicm09:07:09

@donyorm depends what you mean by "preferred alternative" boot-reload has far more adoption.

donyorm09:07:57

Ok, thannks

richiardiandrea09:07:08

@donyorm I would agree with the above and that also means that contributions are valuable 😀😀😀

donyorm09:07:31

What's the difference between the two? Why do they both exist?

dominicm09:07:21

One uses the figwheel client. One uses one that was written for boot-reload.

mpenet10:07:54

how do you have your resources added to an uberjar?

mpenet10:07:59

seems it's not added by default

mpenet10:07:08

nervermind, found it

martinklepsch10:07:39

@mpenet just for posterity: files in :source-paths are not included in the build output, files in :resource-paths are

mpenet10:07:02

yup noticed, it's actually on the readme, silly me

mpenet10:07:32

is there an equivalent of lein check ?

martinklepsch10:07:39

@mpenet what does lein check do?

mpenet10:07:02

` $ lein help check Check syntax and warn on reflection.

mpenet10:07:45

I think it basically aot the whole project

mpenet10:07:11

so it just load files with warn-on-reflection on

martinklepsch10:07:50

there’s boot aot --all but I don’t think that handles the warn on reflection thing

martinklepsch10:07:05

(deftask check []
  (comp (with-pass-thru _
          (set! *warn-on-reflection* true))
        (aot :all true)))
maybe something like this

mpenet10:07:41

yeah I came up with something similar, testing it now

mpenet10:07:51

hmm not working 😞

martinklepsch10:07:56

Can't set!: *warn-on-reflection* from non-binding thread as well?

martinklepsch10:07:02

(deftask check []
  (comp (with-pass-thru _
          (alter-var-root #‘*warn-on-reflection* (constantly true)))
        (aot :all true)))

mpenet10:07:33

it doesn't catch all reflections, probably just the one in my sources, not in deps

mpenet10:07:52

lein check seems to be better at this

martinklepsch10:07:20

Agree. Maybe something like lein-check can be added to boot-check: https://github.com/tolitius/boot-check/issues/8

mpenet10:07:12

actually the with-pass-thru version doesn't warn reflect on my own code either

martinklepsch11:07:46

yeah, I think it’s a per namespace thing so you need to bind it around the load call for each namespace individually

martinklepsch11:07:51

(just like how it’s done in lein’s check.clj)

martinklepsch11:07:29

I guess it wouldn’t be too hard to port that function to boot but don’t have time for it right now

donyorm11:07:22

Whenever I run boot cljs target I'm getting the error NoSuchFileException: target/cljsbuild, even if I manually create the target/cljsbuild directory. Anyway to avoid this?

martinklepsch11:07:00

@donyorm can you gist your build.boot?

donyorm11:07:58

Main.cljs.edn:

donyorm11:07:02

{:require [test.core]
 :compiler-options {:main "test.app",
                    :asset-path "/js/out",
                    :output-to "target/cljsbuild/public/js/app.js",
                    :output-dir "target/cljsbuild/public/js/out",
                    :source-map true,
                    :optimizations :none,
                    :pretty-print true}}

martinklepsch11:07:18

@donyorm that build.boot has a bunch of things that could be improved, have you tried starting with a build.boot as it is generated by tenzing and similar projects?

martinklepsch11:07:39

Usually it is not recommended to use target/ in the way you do, and instead utilize boot’s tmp directories (which doesn’t require any explicit action from your side)

donyorm11:07:43

that was it. I was copying a lein config, hence the seutp

martinklepsch11:07:13

@donyorm things working now?

martinklepsch11:07:23

usually you don’t even use the target task during dev

donyorm11:07:39

appear to be, we'll see what happens

martinklepsch11:07:51

cool, good luck

martinklepsch11:07:54

gotta go myself

donyorm11:07:30

Ok new issue, when I run a task with boot-reload it produces the error ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.String. My build.boot is just a few lines above. The task I'm running is called figwheel, it's at the bottom.

donyorm11:07:57

What could be causing that?

richiardiandrea11:07:43

@donyorm I suspect boot-cljs, do you see it in the stacktrace?

donyorm15:07:29

richiardiandrea: It does appear in the stacktrace, but I have no issues if I run boot cljs by itself.

dominicm15:07:34

Is there any way to rewrite the path being reloaded in boot-reload? I have sass files which are served at /foo/app.css, but they are stored in /bar/public/app.scss

dominicm15:07:21

Looks like I need a combo of asset-path & target-path

richiardiandrea15:07:19

dominicm: there is a description of the params in the help, but I remember having talked with Juho at some point asking whether we should get rid of some of them or change the name. Asset-path should give you control the path after the

richiardiandrea15:07:22

also where you are serving from counts of course, so if you are serving public that app.css will be in ./

dominicm15:07:58

I think I found the naming/docstring confusing. I thought it was to do with where boot-reload put it's own js files.

dominicm15:07:40

or not 😛

phreed15:07:18

What is the relationship between the versions of Clojure being used by boot? I get the following warning... Classpath conflict: org.clojure/clojure version 1.8.0 already loaded, NOT loading version 1.9.0-alpha17 It appears that it is due to a version mismatch between what is in boot.properties BOOT_CLOJURE_VERSION=1.8.0 and that found in the build.boot [org.clojure/clojure "1.9.0-alpha17"] Is their any point of having the clojure dependency if it is ignored by boot?

donyorm15:07:42

@richiardiandrea so you think boot-cljs is causing the class cast exception? Why doesn't it occur when I call boot cljs then?

richiardiandrea15:07:12

donyorm: this looks like a boot-cljs bug

donyorm15:07:26

Interesting that it only shows when I use a reload task.

richiardiandrea15:07:42

that is boot's magic middleware pattern

richiardiandrea15:07:19

I am checking probably there is something else going on there 😄

richiardiandrea15:07:01

I can reproduce, which is good

donyorm15:07:26

That is always good

donyorm15:07:37

Let me know if there is anything else you want me to test

mpenet15:07:55

anyone knows of a https://github.com/riemann/riemann/blob/master/tasks/leiningen/fatdeb.clj equivalent for boot? or should I just port it

mpenet15:07:36

google says it doesn't exist

sparkofreason16:07:26

Some time ago I had a nice combination of boot tasks and scripts to produce a docker image from a Clojure project. Wondering if there's any more "standard" or packaged way to accomplish same today.

alandipert16:07:31

@dave.dixon i know @hlship has done some work in that area, not sure what the state of the art is

hlship16:07:02

"art" would be generous

hlship16:07:37

I think some of what I was trying to accomplish can now be done about as well using Docker 1.17 multi-stage builds.

hlship17:07:56

What I was doing was trying to avoid leaving unwanted big artifacts in the output image, the kinds of things you'd get by using Lein and/or Maven to obtain dependencies. Multi-stage builds largely address that ... it allows you to run an image and copy to the next stage just the output files you need.

sparkofreason17:07:45

Thanks, will ponder that. I'm trying to dockerize onyx jobs. Previously I think I just built an uberjar and dumped that into the container.

hlship17:07:20

I haven't used multi-stage builds yet, but the intent is that you can build inside Docker and essentially discard everything but your intended artifacts. You can even use one base image to build, and an entirely different base image for the final image.

danielcompton21:07:28

Anyone looking to use multi-stage builds, be aware it's only available in Docker 17.06 which has just come out a few days ago

danielcompton21:07:37

Here's what I came up with. It doesn't have any Java server config btw

danielcompton21:07:49

I'm not using it because it took waaaaaay to long to download all the deps

danielcompton21:07:35

I looked at mounting my ~/.m2 in the directory, but it seemed like there were some gremlins there

danielcompton21:07:11

relating to file ownership if the container downloaded any dependencies