Fork me on GitHub

Bore da, Gavin-John


Question for the day: Why Boot?


More versatile than Lein. It copes better with doing more than one thing (serial, parallel) because it supports composition.


@malcolmsparks: succinct and persuasive as always Malcolm


As someone who only gets to write toy projects the cognitive load of learning it and throwing away lein templates just doesn't make it worth me bothering atm


love lein templates a lot. also hate lein templates so much.


@agile_geek: dunno what kind of toy projects you're doing but there are templates for boot based projects as well


pros: get shit working quick cons: everything that does the same thing does it differently


@martinklepsch: good to know but for the moment I just have never hit anything in Lein that has restricted me from what I've been doing.


@xlevus: were those pros/cons for Boot or Lein templates?


I find that with boot templates are much more concise because a lot is handled in tasks. just using a task adds very little code to your project .


@agile_geek: lein. They're all very rigid. Not and composable, and I find that frustrating when wanting to use say, figwheel with pedestal


@xlevus: I agree. As lein templates don't compose you need to know which to pick to get your project started then beg, borrow and steal from the others.


Still don't have a strong enough reason to use Boot tho!


I used boot for a 'bash script'


that worked out nicely


slowest f* bash script ever. but that's not boots fault


I think if I wrote Clojure for a living I might expend the effort to learn Boot but I don't so I don't


We use lein for all of our clojure projects - of which there are dozens - it's prescriptive - but it's familiar and repeatable... I actually like it a lot; though it does definitely have shortcomings around using plugins/templates etc... and if you do want to do genuinely need to do more scripting with your builds, boot is probably better.... This said most of our projects haven't needed much extra scripting.... The biggest problem we have with lein, and I don't think boot solves this; though the extra scripting would help - is with CI... i.e. I'd like subcomponents in separate repos trigger downstream dependencies to build with that version - if downstream fails I want the build to be removed from the .m2 cache. I know it's possible to do this with some extra scripting ontop of boot/lein; and in principle it's not too complicated... but in practice it's a bit messy because you have to combine lots of individual pieices... e.g. lein-ancient/clj-ancient, with some custom m2 cache clearing code that can isolate m2 caches across multi project builds etc... Then tying this into your CI through env vars/configuration etc will be an additional challenge.


@agile_geek: on yapster we have a bunch of lein projects and a single boot project - lein is easy and fine for libs and simple builds, but boot is more concise, comprehensible and flexible for something like a front-end project which requires concurrent less compilation, cljs builds, http serving and repl


@rickmoynihan: have you looked at lein-voom ? it solves the repo coordination problem nicely... i even got it to work with boot through a glorious hack


@mccraigmccraig: yes I have looked at it - thanks for reminding me though - it's one of the options I was meaning to explore... When I find time I plan on spiking somethings out on a new build server before adopting anything wholesale


Another thing I'd like to figure out is how to get a CI server to inspect project.clj dependencies, and use the information in there to know whether it has build jobs for any of those dependencies; and if so trigger downstream builds when things change etc... I know the maven support in jenkins (and presuably other CIs) is quite good; and I believe it will do things like this for maven projects; so was wondering if anyone has setup their CI build as a java/maven project and used the CI's knowledge of the info from pom.xml to solve these issues.


One problem I have is that our CI isn't really doing integration if people always have to version lock the dependencies; you get integration with SNAPSHOT builds of course - but they're not repeatable and you can poison the m2 cache for all projects


voom does look really good


it's very simple - and you never poison your cache

Pablo Fernandez12:08:17

I’m becoming available very soon. Does anybody know of any Clojure contracting positions?


any recommendations for a browser+cloud-based BI tool which won't bankrupt me ? in particular i want to join time-sequenced events to user and group metadata, and filter, aggregate and visualize - i.e. normal OLAP/BI operations... all stuff which is straightforward to build with ElasticSearch, but i would like to avoid building if possible


weirdly there don't seem to be any off-the-shelf packages for ES


(ES can't do generalized joins, but for my use-case in-memory joins are mostly fine)