This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-26
Channels
- # bangalore-clj (1)
- # beginners (12)
- # boot (48)
- # cider (56)
- # clara (1)
- # cljs-dev (15)
- # clojure (455)
- # clojure-austin (2)
- # clojure-dev (33)
- # clojure-italy (26)
- # clojure-nl (6)
- # clojure-poland (10)
- # clojure-russia (23)
- # clojure-spec (33)
- # clojure-uk (62)
- # clojurescript (37)
- # code-art (2)
- # cursive (12)
- # datomic (48)
- # funcool (1)
- # juxt (16)
- # leiningen (13)
- # off-topic (12)
- # om (23)
- # onyx (16)
- # other-lisps (5)
- # parinfer (2)
- # pedestal (28)
- # re-frame (60)
- # reagent (8)
- # ring (1)
- # ring-swagger (15)
- # spacemacs (5)
- # specter (53)
- # test-check (2)
- # unrepl (8)
- # vim (14)
Hi guys, we keep running in problem when zipping assets with boot. Basically our task is
`
(comp
(build-assets)
(sift :include #{"paths/to/assets"})
(target :dir #{"path/to/target"})
(zip :file (str "assets-" version ".zip"))
(sift :include #{#"^(.+?).zip$)"})
(target :dir #{"path/to/target"}))`
The problem we have is that the zip randomly doesn't include some of our assets : sometimes it's images, sometimes it's css. We're keen on adding a (wait :time 1000)
between target
and zip
to make sure everything is written to the fileset before zipping it. Anybody faced similar problems ? I read the source of zip
, very small, I didn't see anything weird but I'm no Boot/Java guru.
djebbz i haven't heard of that problem and am not sure how to fix. but i did see this recently: https://github.com/manenko/boot-zip
might be worth trying to see if it fixes. but if you have more info about your setup and wouldn't mind filing a bug, that would be v. helpful
For the time being we added the (wait)
call and it seems to do the job. Need more usage to see if it happens again. At this moment I'll investigate more.
It may be related to the setup, it always works locally but often doesn't on Jenkins...
no problem
to add a local jar to the classpath, do you just add the jar's path to :source-paths
? i'm getting a java.nio.file.DirectoryNotEmptyException
@sekao https://github.com/boot-clj/boot/blob/master/doc/boot.pod.md#add-classpath
@martinklepsch thanks, am i correct that this will only work within a pod you create via make-pod
?
@sekao no, the function should work in general for the main (and children) pod
> and will attempt to add that path to the right classloader (with the search rooted at the current thread's context classloader).
the weird thing is, after running add-classpath
i can require
a namespace from the jar at the top level of my build.boot. but if i try to build an uberjar of my project, which requires said namespace, it says it can't find it on the classpath
if i remove the aot
task, there is no error, so i suppose my project needs the namespace too early...
sekao currently the fileset entangles files and the classpath. as such the notion of environment differs between add-classpath and fileset
so add-classpath adds it to the build.boot context, but that's not where classpaths that filesets have starts from
luke vanderhart disentangled recently to nice effect, https://github.com/arachne-framework/arachne-fileset
I liked the project above as well 😄
is it common for the boot-cljs
to run twice in a row on file change? I wonder if I have it configured incorrectly (bad ordering of task composition) or my source-paths are incorrect or something (change #1 invokes immediate change #2)
100% of the time I get this on a .cljs file change:
Compiling ClojureScript...
• main.js
Compile sources, elapsed time: 1456.544556 msecs
Compile sources, elapsed time: 150.422101 msecs
Writing target dir(s)...
Elapsed time: 3.385 sec
@lwhorton That message is not from boot-cljs, but from ClojureScript compiler, there are two compile stages, that is why there are two "Compile sources" messages
Ah. Bummer. It’s getting pretty slow now that I have a sizeable project and I was hoping I was just configuring things improperly. That being said, I also have another task that logs something like starting task foo... ended foo, elapsed time XXXms
. that message shows up twice too, which is maybe not expected?
The second Cljs compile stage compiles :preloads
namespaces and their dependencies
I can't comment about other tasks without more information
but thanks for letting me know about the 2 stage compilation, i would have chased that for a while
One thing that can help with Cljs is to ensure that the project is constructed so that the often modified files are not dependecies of too many other namespaces, i.e. when a file is modified, as few as possible other files need to be recompiled
blogpost right there 🙂
But if the compile times are around 1-2 seconds, I doubt that is the problem. I have some projects where changing a common.*
namespace triggers the recompile of everything and takes ~15 seconds.
Seeing that you are using target
task, it might be helpful to check if some unnecessary files are being written, like node_modules
which can contain thousands of files. You can use sift
to remove the unnecessary files.
Unrelated note, is there an api to get a particular dir in the tmp fileset? The fileset api seems to be all pointing to ways to get files, but suppose I have 2 tasks that want to share a particular dir between them?
(this is a really weird task, but essentially I’m installing npm deps into a particular dir, such that I can install a whole bunch of things once and have steps 2, 3, 4, etc. utilize those installed programs inside of the node_modules dir)
I use:
(defn by-dir
"Gets files matching directory names"
[dirs files & negate?]
((boot/file-filter #(fn [f]
(= (.getParent f) %))) dirs files negate?))
lwhorton filesets don't contain dirs per se, since the objects in them are addressed by content. works kind of like aws S3, if you are familiar. however you can scan the paths looking for some prefix
other than picking some prefix meaningful to your tasks, you could add metadata to the fileset object
or, add a single "manifest" file to the fileset that contains paths to other files that are meaningful for your task
I see, so I could do a :
(binding [u/*sh-dir* my-special-prefix-path]
(u/dosh "npm" "install" "--depth" "-1"))
and commit those files into the fileset, Then later lookup those files
(binding [u/*sh-dir* (.getPath my-special-prefix)]
(u/dosh "my-special-path/node_modules/.bin/my-exec"))
or something along those lines*@juhoteperi +5 points for you and Gryffindor. filtering out files in post-task cleanup cut off a lot of recompilation time.
@lwhorton also consider that you might not need target
at all (I don’t in most projects)