[brandonbloom]

> it's really useful just ergonomically to be able to use command line arguments to configure ad-hoc builds

It's largely also what contributes to "works for me" build environments... It's better to have a just one way to do it interface and discourage excessive tinkering with parameters. The more parameters, the more likely for your dev env to be unstable across individual checkouts or developers. I know it's idealistic, but I think we should strive for zero-arg builds, which oddly means not making it easier to configure them.

I'll have to think on all the other stuff you wrote, since it's not totally clear to me yet. I may ping you again after I noodle a bit.

[michaniskin]

Your point about repeatability is valid. As a policy matter we would never advocate building a project without codifying the process as zero-arg tasks in the build.boot file. You can see this in our own projects (eg. https://github.com/tailrecursion/boot-useful/blob/master/bui...). This project has one way to build the project jar file:

    (deftask build-jar
      "Build project jar file."
      []
      (comp (pom) (add-src) (jar) (install)))

When you build the jar file you just do

    boot build-jar

This ensures repeatability, etc.

But we don't only use boot for repeatable builds! Boot is in a unique position in that it's on the intersection of application and environment. That is to say, boot can be used to "bootstrap" the application. With boot we can create sort of self-configuring applications, where the entry point of the application is the build.boot file. This is a very clear win, for example, when running Clojure applications in docker on Elastic Beanstalk, etc. (We'll write that up, too.)

[bsima]

> running Clojure applications in docker on Elastic Beanstalk, etc. (We'll write that up, too.)

Yes. I would love to see a writeup on that.