Fork me on GitHub

@jeroenvandijk how stable has that been?

eccentric J03:01:35

Is there a boot noop to put into a pipeline when conditionally building it? Like (comp (when (= :env :dev) (draft))?


@jayzawrotny ok so the boot task is like a double wrapped function


when you create a task you are returning a function that returns a fileset


so to conditionally wrap that you would use a cond->


I do it often, one sec I have demos

eccentric J03:01:40

Ah right, the middleware so would need to be like (comp (if (= :env :prod) (draft) (noop)) where noop is like (fn [next-handler] (fn [fs] (next-handler fs))


yeah I find the threading macro easy tho

(cond-> (identity)
  (= :env :dev) (comp (dev)))


that way I can build up a pipeline of conditional tasks


I could also see a really easy reduce-task that takes a coll of tasks and reduces them to a pipeline

eccentric J03:01:52

  (perun/markdown :md-exts {:all true})
  (perun/gravatar :source-key :author-email :target-key :author-gravatar)
  (perun/render :renderer ')
  (perun/collection :renderer ' :page "index.html")
  (perun/tags :renderer '
  (perun/paginate :renderer '
  (perun/static :renderer ' :page "about.html")
  (perun/rss :description "Eccentric J's Blog")
  (cljs :optimizations (if (= build-env :production) :advanced :none))
  (clean :exclude #{#".git"})
  (target :no-clean true)
Is my pipeline thus far, some of those steps are conditional depending on env and some of those steps may take different args depending on the env. Maybe I should manipulate a list then reduce it into a pipeline?


I think the correct answer to your question tho is just return an identity fn as the task, so it returns the previous tasks fileset

eccentric J03:01:31

Otherwise I’m going to have (cond->) all over the place.

eccentric J03:01:49

Thanks, though you got me thinking I need to rethink my approach


ok I see what you are doing, take a look at what I have done here:

eccentric J03:01:15

[meta] seems really nice! I may have just found a stack for clojure desktop app dev!


yeah we are using it everyday


those tasks use the thread approach, it seems you probably want to breakup the pipeline into smaller sub-tasks

eccentric J03:01:22

Ok, I was just starting to think that 🙂

eccentric J04:01:31

(deftask build
  "Build the blog source and output to target/public"
  [e build-env BUILD-ENV kw    "Environment keyword like :dev or :production"]
  (let [prod? (= env :prod)]
    (->> [(perun/global-metadata)
          (perun/markdown :md-exts {:all true})
          (when-not prod? (perun/draft))
          (perun/gravatar :source-key :author-email :target-key :author-gravatar)
          (perun/render :renderer ')
          (perun/collection :renderer ' :page "index.html")
          (perun/tags :renderer '
          (perun/paginate :renderer '
          (perun/static :renderer ' :page "about.html")
          (perun/rss :description "Eccentric J's Blog")
          (cljs :optimizations (if prod? :advanced :none))
          (clean :exclude #{#".git"})
          (target :no-clean true)
         (keep identity)
         (apply comp))))

eccentric J04:01:28

Going this route, I think this should keep things pretty clean. I didn’t see a natural split in the steps because they all work towards building the blog. Without any of these steps I’m not sure the result would be meaningful.


If it builds ™️

eccentric J17:01:49

Is there a way to get watch to respond to changes in a target/public directory instead of the resources dir?


the target dir is not immutable, it's the final IO at the end of the pipeline

eccentric J23:01:14

Sounds like I’m trying to use it incorrectly then.


one of the reasons why tasks like watch can be made simple and reliable is that they only manipulate immutable filesets


so you can "roll back" to a previous state easily

eccentric J23:01:22

The intention was to serve the files compiled to target/public as a website and when those files change run through boot-livereload. Sounds like I need to put those in the build pipeline.


you can use :asset-dirs or :resource-dirs

eccentric J23:01:00

Actually, let me back up. I’m learning boot while developing a static site with I had a watch task that would build the markdown files, gen the html files, compile the scss and the cljs. But I’m curious if I could set it up to be a bit smarter. Currently if I change a markdown file both the scss and cljs get recompiled.


are you sure they're really getting recompiled?


so there are two usual approaches to build tooling

eccentric J23:01:47

Well the tasks are firing and output is being logged


you have an approach like Make


where it computes dependencies and triggers tasks that need to run


boot doesn't do it that way


boot always runs the pipeline every time


but each task can hold a reference to the previous immutable fileset


and it can efficiently diff the files


so each task is responsible for figuring out for itself whether it needs to do any work or not


so while those tasks will run, they probably are not actually doing any work


they diff the new and old filesets and see that no scss files changed, and just pass the cached results from the previous run onward

eccentric J23:01:49

I see, unfortunately they do slow down the recompile a bit. It’s not the end of the world though.


perhaps there is a reason why they need to recompile something?


or perhaps there is a bug in the task that can be found and fixed

eccentric J23:01:36

No wait, I see it

eccentric J23:01:39

You’re right


no line numbers there but see the fileset-diff part?

eccentric J23:01:54

Yeah I see it now


yep exactly


the reasoning there was that only the task itself really knows what it depends on


it can get pretty complex


the build tool can't really know

eccentric J23:01:35

Good point. Also, I think I see the issue. It’s setup to diff the entire fileset which is why it’s always recompiling for me. Does this mean I could create another task to compose a sift with just .scss files with boot-sass to make it more efficient?


do you have a large number of scss files?


i know sometimes those things can have a ridiculous number of files

eccentric J23:01:14

Nope, so far just one but if I was using this build system for a bigger site it’s possible.


it's slow with only a small number of files?


the diffing is usually quite fast


since it's all immutable it can do various tricks

eccentric J23:01:50

I don’t think it’s the diffing that’s slow, I’m just saying if I change a markdown file: the fileset this task receives will be different than the previous fileset it diffs against and will recompile


it will only recompile if a scss file changes though


at least that's how it looks from the code


the (when (seq sources) ... part

eccentric J23:01:13

Right, and sources is the result of diffing filtered by the sass extensions


sources is the .scss files that changed


seems like it should skip recompiling if only a markdown file is changed, no?

eccentric J23:01:37

Agreed, boot-sass is definitely designed to work that way.

eccentric J23:01:08

I’ll try again tonight by removing previous steps from the build pipeline until it behaves as expected.


you can try boot -vv ... too


that will log a bunch of debug messages that might show something