I recently met with @alandipert and @micha to talk about the future of boot. I will be officially taking over as maintainer, you can read about it here: https://medium.com/degree9/boot-future-boot-e1948562d8d3
You can also now buy your official boot-clj swag over at http://OpenSwag.co https://openswag.co/products/boot-clj-mug
@flyboarder thanks for taking over. is there any public information about why the original maintainers step down?
@borkdude i don't use boot (or clojure) professionally anymore and micha is devoting his OSS energies to hoplon
we still plan on meeting with matt monthly to help him triage/ideate/deploy or however else he needs our help with
so, we'll still be involved with the project
@alandipert makes a lot of sense. what do you use now, I saw some R related tweets coming by
thanks for the time devoted to boot and making it awesome
i work on dev tools for R at rstudio, makers of the IDE
that sounds cool!
thanks it's been really fun to work on!
and yeah, R is also really fun. lispy, even
My wife uses it regularly at her data science job
neat, yeah data science definitely lends to R
Whatβs the boot equivalent of lein install?
it's a pipeline of individual tasks
Oooh oops this repo already has a task like that. Thanks!
to install anartifact in your maven cache you need a pom.xml, and a jar
π
Boot reminds me of gulp for js, which I loved. Composing pipelines is a great idea to me. However, boot has more jobs to do for clojure that kinda overlap with what npm does for node.
gulp, at least the last time i looked at it (a few years ago) has the issue that the pipeline isn't working on data passed from one step to the next -- the steps are working on a big mutable tree of files
i think boot is more similar to the "broccoli" tool in the js space
but yeah, composing pipelines is what boot is all about
I thought broccoli uses the trees and gulp uses streams to work on vinyl file wrappers?
yeah that's my understanding as well
it's just that they're all mutable, whereas inboot the "file sets" are immutable
so like if you have a pipeline boot task1 task2
task1 can never see any of the changes task2 makes to the files
so you can safely do like boot watch task1 task2
and when the pipeline reruns you don't get any weirdness
That makes sense. I think gulp was intended to work that way but itβs difficult to enforce gulp.src('**/*.scss').pipe(sass.compile()).pipe(gulp.dest('./public'));
where steps in the pipeline are only supposed to operate on data flowing in and push data out.
In so far, I like boot a lot. It seems even easier to work with.
a lot of tradeoffs involved for sure
hard to get that right π
boot tasks receive a "fileset", do some work to the files in that fileset, and then create a new immutable fileset they pass to the next task
kind of like git
each task in the pipeline gets the HEAD, adds their own commit, and passes the new HEAD to the next task
Is the new fileset given to the second task based on the first task fileset or completely separate?
when the watch task reruns the pieline it just basically does reset --hard
it's like git, there is structural sharing
it's a tree of blobs
and each fileset is immutable
boot.core/commit!
makes a new fileset
Thanks, this makes more sense now.
great
Is it common\reasonable to use lein for deps and boot for tasks?
boot resolves dependencies with the same maven machinery as lein
and the :dependencies
specification is identical
For a more specific use case Iβm working on some cljs lein templates and the repo is lein based but I would like to have some tasks while developing the template for deploying and updating versions in README. Does it make sense to throw boot into the template project for that?
you might want to slurp dependencies out of a project.clj
file inside your build.boot
like you can read in the project.clj and extract the dependencies inside your build.boot
because the build.boot is just a clojure program
you can do anything in there