This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-06
Channels
- # beginners (90)
- # boot (83)
- # cider (39)
- # clara (4)
- # cljs-dev (124)
- # cljsrn (10)
- # clojure (208)
- # clojure-boston (1)
- # clojure-italy (13)
- # clojure-nlp (3)
- # clojure-russia (34)
- # clojure-spec (63)
- # clojure-uk (101)
- # clojurescript (65)
- # community-development (13)
- # copenhagen-clojurians (1)
- # core-async (1)
- # cursive (24)
- # datascript (1)
- # datomic (65)
- # emacs (20)
- # graphql (20)
- # hoplon (21)
- # instaparse (18)
- # jobs (5)
- # jobs-discuss (2)
- # leiningen (8)
- # luminus (32)
- # midje (1)
- # mount (3)
- # off-topic (18)
- # om (10)
- # parinfer (6)
- # pedestal (2)
- # planck (2)
- # precept (22)
- # protorepl (7)
- # re-frame (45)
- # reagent (9)
- # ring (1)
- # ring-swagger (4)
- # rum (2)
- # spacemacs (5)
- # sql (2)
- # unrepl (13)
- # untangled (8)
- # yada (5)
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?
@mpenet https://github.com/clojure-emacs/cider/pull/2027 use .dir-locals.el again 🙂 no more security warning (do an update ofc)
So am I right that boot-figreload (https://github.com/boot-clj/boot-figreload) is the currently perferred alternative to lein-fighweel for boot?
@donyorm depends what you mean by "preferred alternative" boot-reload has far more adoption.
@donyorm I would agree with the above and that also means that contributions are valuable 😀😀😀
@mpenet just for posterity: files in :source-paths
are not included in the build output, files in :resource-paths
are
@mpenet what does lein check do?
there’s boot aot --all
but I don’t think that handles the warn on reflection thing
(deftask check []
(comp (with-pass-thru _
(set! *warn-on-reflection* true))
(aot :all true)))
maybe something like thisCan't set!: *warn-on-reflection* from non-binding thread
as well?
(deftask check []
(comp (with-pass-thru _
(alter-var-root #‘*warn-on-reflection* (constantly true)))
(aot :all true)))
Agree. Maybe something like lein-check can be added to boot-check: https://github.com/tolitius/boot-check/issues/8
yeah, I think it’s a per namespace thing so you need to bind it around the load
call for each namespace individually
(just like how it’s done in lein’s check.clj)
I guess it wouldn’t be too hard to port that function to boot but don’t have time for it right now
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?
@donyorm can you gist your build.boot?
{: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}}
@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?
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)
@donyorm things working now?
usually you don’t even use the target
task during dev
cool, good luck
gotta go myself
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.
@donyorm I suspect boot-cljs
, do you see it in the stacktrace?
richiardiandrea: It does appear in the stacktrace, but I have no issues if I run boot cljs
by itself.
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
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
also where you are serving from counts of course, so if you are serving public
that app.css
will be in ./
I think I found the naming/docstring confusing. I thought it was to do with where boot-reload put it's own js files.
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?
@richiardiandrea so you think boot-cljs is causing the class cast exception? Why doesn't it occur when I call boot cljs
then?
donyorm: this looks like a boot-cljs
bug
that is boot
's magic middleware pattern
I am checking probably there is something else going on there 😄
I can reproduce, which is good
anyone knows of a https://github.com/riemann/riemann/blob/master/tasks/leiningen/fatdeb.clj equivalent for boot? or should I just port it
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.
@dave.dixon i know @hlship has done some work in that area, not sure what the state of the art is
I think some of what I was trying to accomplish can now be done about as well using Docker 1.17 multi-stage builds.
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.
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.
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.
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
Here's what I came up with. It doesn't have any Java server config btw
I'm not using it because it took waaaaaay to long to download all the deps
I looked at mounting my ~/.m2 in the directory, but it seemed like there were some gremlins there
relating to file ownership if the container downloaded any dependencies