Hey there I am having a little trouble with changing the name of a file. I have tried doing an io/copy and a str/replace but neither seem to work. I'm not sure what the best way to go about it is. I basically want to take a template.html file and then change it to the path of a bidi route (eventually I will map the task over it..?). Anyways here is the current code.

(def next-route (path-for app/my-routes :community))

(defn render-template
  [in-file out-file]
  (doto out-file
    io/make-parents
    (spit (str/replace (slurp in-file) "{{CONTENT}}" "Happy times!"))))


(deftask generate-page []
  (let [tmp (tmp-dir!)]
    (with-pre-wrap [fileset]
      (empty-dir! tmp)
      (let [in-files (input-files fileset)
            template (by-name ["template.html"] in-files)]
        (doseq [in template]
          (let [in-file (tmp-file in)
                in-path (tmp-path in)
                out-path in-path
                out-file (io/file tmp out-path)]
            (render-template in-file out-file)))
        (-> fileset
            (add-resource tmp)
            commit!)))))

I did the io/copy at

(tmp-file (made-a-copy in one-being copied)

out-path (replace-name in-path "/template.html" next-route)

@grounded_sage if I remember correctly there should be a move in the sift task

Unfortunately this hasn't seemed to have gotten me much further. I have attempted this

(defn change-name [path]
  (sift path :move{#"template.html" next-route}))

@grounded_sage sift is a task so you'll need to use it in the boot pipeline, like this (sift :move{#"template.html" next-route}) (note there's no path anymore)

@martinklepsch so is sift something I use inside of the generate-page task as I mentioned above? I currently have out-path (change-name in-path inside the let.

No you'd use them in the task pipeline like (comp (generate-page) (sift ...))

ok.. So essentially if I want to pick up the template.html from resources and map the bidi routes over it with the corresponding rum rendering. I would do something like map the bidi route handlers over (comp (generate-page (sift ...)))

Sorry if that sounds confusing as I actually don't even know what I am saying xD

generate-page returns a fileset with a file template.html in it. sift is a task that can modify the fileset. if you want template.html to be copied to multiple places you can do something like (comp (generate-page) (sift :copy {"template.html" "somepath.html"})) — except there is no :copy option for the sift task

lol

He starts to wonder if it was worth building his own static site generator 😆

😄

It seems like I would need to retain the original fileset with template.html. Then map over the bidi routes with the original fileset (generate-page) and (sift...) commiting each change. Then deleting template.html from the fileset when it is all done so it doesn't end up in the target folder.

Hey, folks. Is there any boot alternative for lein's :omit-sources option?

@armed is that to omit source files from a jar?

@micha exactly

ah yes, there is no option for that, but only files in :resource-paths will end up in jars

so if you add the source files you want to have on the classpath at build time to :source-paths they won't be in the jar

both :source-paths and :resource-paths are on the classpath

but only :resource-paths will be packeged by packaging type tasks

well, that’s strange. I’ve boot build-ed sample project from https://github.com/adzerk-oss/boot-uberjar-example and got all sources in project.jar.

also you can use the sift task to remove things from the fileset before the jar task

sure, look at line 4 of the build.boot

everything in the "src" dir will end up in the jar

this document explains how it all works: https://github.com/boot-clj/boot/wiki/Filesets#definitions

Oh, thanks. I didn't look at first lines. Going to try now

but really in hindsight i think the sift task would be the way to go

rather than having :source-paths and :resource-paths

how to do it with sift, I couldn’t find option for deleting files.

you can use the :include option

include with revert?

and if you want to exclude you can use the :include option with :invert

yes

@micha thanks for help. I need to familiarise with this a litle bit weird logic

which part is weird? the :invert thing?

yep

it's like grep

with -v

ah, another question: what does exclude do in uber task? I tried to exclude sources with it.

but it didn’t help obviously

(uber :exclude #{#”.*clj"})

it excludes things from what it explodes from jar files

the uber task only adds things to the fileset

it can't remove things

the purpose of the uber task is simply to explode files from dependency jars and add them to the fileset

Ok, I got it. Thank you again!

👍

it' skind of like the unix model

a collection of tasks that each do one thing

and you connect them in a pipeline

I see, it’s like grunt vs gulp

leiningen is grun, boot is gulp. I mostly do frontend stuff 🙂

are you familiar with the ember one, i think it's called broccoli?

boot seems to be very similar to that in some ways

especially with respect to how the tasks know which work needs to be done

I like unix way, but didn’t think about boot in that way.

Now all seems more clear

boot tasks are like unix processes, and the "stuff" that is piped from one to the next is the fileset

ok, right. fileset is like requestmap in ring

exactly

immutable

which is key

so a task can keep a reference to the fieset it gets

and later do things like compare it against another fileset

things like that

So I can write my own task, which modifies fileset by removing unwanted files from it, and passes to next task.

exactly yes

that's what the sift task is about

it has all kinds of fileset transformations

and that's all it does

whoa! It’s much-much better than lein.

@micha where I can look for structure of fileset map? What fields it has, etc.

the fileset is a record type

@armed I think your looking for: https://github.com/boot-clj/boot/wiki/Filesets#edn

you would probably want to interact with it via protocol methods

thanks!

yeah i recommend looking at https://github.com/boot-clj/boot/blob/master/doc/boot.core.md for api functions that do what you want

the structure of that record is not part of the official versioned api

@micha good to know

thanks

yep, you can change structure, but leave protocols untouched.

we won't change anything unless we really need to of course

How do I determine the roles that get applied to generated files in a tmp dir (tmp-dir!) when they are are added to the FS via add-resource?

"resource" things get both input and output roles

there is a matrix here: https://github.com/boot-clj/boot/wiki/Filesets#fileset-components

So given that they will have an output role as well, that will mean they will be emitted to the target dir?

yes

As a general rule should all tasks that produce files emit to the target dir?

i think so yes

if a task creates a file, it's safe to assume that the user wants to include it in the artifact

this isn't always true, but i think is a reasonable default

I was envisaging a "pipeline" of tasks where each sub-task applied a transformation as part of the bigger whole

in general I don't see the user being interested in the intermittent states of the files

which I guess begs the question "why run as seperate tasks?"

separation of concerns is helpful sometimes

yeah that's what I figured

not always

i like having things decoupled because i don't like spending a lot of time on the build tooling

so if i can hack something together to get a project moving i'll do it

So I was unsure if each task should be writing to the target dir

separation of concerns really helps there

but I think the answer is that yes, if you add files to FS via add-resource it will be going in the output

tasks really shouldn't know about any named place in the filesystem at all

when you have a named place in the filesystem you introduce unmanaged shared global state

yeah I follow

I like this about Boot

oh i see what you mean

you weren't talking about tasks writing directly to the target directory

yeah

implicitly via the role that is applied

right yeah

the user can always use sift to remove unwanted things

and most of the time when a task creates a file that task can't know if it is an intermediate ssource or a final artifact

like some other task may process it further

or maybe not

so just having the default be to add thigns as resources seems at least consistent and easy to fix with sift later

So is it common for a task to remove files from the FS that have a output role?

i.e. if "task A" produces some files, and then "task B" produces some derived files

can "task B" remove the original files, produced by "task A"

it depends

if for example the original file is incompatible with the derived one

like sometimes you can't have two versions of something on the classpath maybe

things like that

It would be more like that the user would not be interested in the artifact of "task A", if they also ran "task B"

right yeah

Does it sound like I'm coming at this from a strange (non-Boot) perspective?

no, that all sounds very reasonable to

me

i think the user generally has some expectation for a given task

about how the task is expected to behave

hopefully it's intuitive

Is there a specific function for removing output files from the FS?

or is that what sift is for?

sift is a pre-made task you can use to do some commonly needed transformations

for things it doesn't support you can make your own task and use functions like boot.core/rm for exaple

to remove things from the fileset

ok, I'll take a look at rm

@micha really appreciate the help

like this (rm fileset (->> fileset output-files (by-re [#"\.clj$"])))

that would return a new fileset that doesn't contain any .clj output files

gottcha

then you'd probably want to commit! that before passing to the next task

yup will do

Thanks again @micha

sure any time

has anyone successfully gotten boot_test's --junit-output-to working with CircleCI's test metadata collector?