It's nice to have complex build/test setups with deep directory structures, I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started. It's also important to be able to just drop into a REPL, load some libraries and go.<p>I think the coolest thing in the pipeline is going to be `add-libs`: <a href="https://insideclojure.org/2018/05/04/add-lib/" rel="nofollow">https://insideclojure.org/2018/05/04/add-lib/</a><p>I made a little orgmode literate demo that is selfcontained (no deps.edn) and even produces some inline SVG <a href="https://geokon-gh.github.io/literate-clojure.html" rel="nofollow">https://geokon-gh.github.io/literate-clojure.html</a><p>I hope this gets added into `core` and single file Clojure programs become a norm. Right now you still need to add tools.deps.alpha into your default user deps.ends for things to work. If this stuff gets into core you could finally send someone a file/gist and they could run it directly. I think that'd really improve the Clojure ecosystem. You can imagine sharing one-file issues/demos/examples and people don't need to reproduce your local setup or clone a whole repo
What all the critics miss is that Lein is "Easy" but tools.deps, tools.build are "Simple". Rich wants all of clojure to be built from simple orthogonal parts that compose together. Ideally a multi-purpose tool like leiningen should be built on top of those simple parts. Other tools can re-use those parts in different ways. With Leiningen - its a great tool but it's a complex thing that you take on an all-or-nothing basis.
I don’t understand why deps was needed and I’m surprised its authors didn’t foresee the confusion it would create. I’m also confused as hell what I should be using now, and the idea of researching deps seems exhausting. I’ll just stick to cutting and pasting onto my leiningen config I think.
I asked some questions on slack related to this, and in case anyone else was confused like me thinking tools.build is a new framework for managing build tasks, that does not seem the be intent.<p>tools.build is a helper lib to write programs that make artifacts such as Jars or Uberjars. It competes with things like depstar in that sense.<p>Tasks are still meant to be managed by deps.edn (tools.deps) and the Clojure CLI by having tasks be Clojure programs that are invokable as either -X, -T or -M, and the idea is you would orchestrate them with another tool like make, a shell command or script, babashka task runner, npm scripts, just etc.<p>This means that any Clojure program can be a "task". All you need to add a new task to a project is define an alias for it in the project deps.edn.<p>Now one caveat is depending on the type of program the task is, you might need to call the alias with either -X, -T or -M option:<p><pre><code> clojure -T:alias
clojure -X:alias
clojure -M:alias
</code></pre>
Ideally all Clojure programs that implement a task move to rely on exec-fns, and thus would be called with -T or -X, which will eventually allow you to chain tasks together where the return of the first task exec-fn will be passed to the next task's exec-fn, so you can compose tasks and run them consecutively from the clojure CLI.<p>So tools.build is just a lib that you can use to help you write tasks (which are just normal Clojure programs), but it is itself a set of exec-fns tasks which you can use directly as an alias as well:<p><pre><code> clojure -T:build-api copy-file :src '"./src/tempo.clj"' :target '"./output/tempo.clj"'
</code></pre>
with alias as:<p><pre><code> :build-api {:deps {io.github.clojure/tools.build {:git/tag "v0.1.6" :git/sha "5636e61"}}
:ns-default clojure.tools.build.api}</code></pre>
I actually have found tools.deps to be pleasurable to use on new projects, though I haven't tried porting anything that previously used leiningen directly. It's simple, it's clear, I guess I find it pretty easy to reason about, but maybe that's because my experience with Lein was more 'copy and paste this huge config' and not really starting from scratch.
Glad they're finally making this stuff first-party. When I messed around and did a Clojure project, the build/dependencies story was the biggest sour note of the experience by far. It was bewildering to have to go set up some third-party tool with a mustache logo before I could follow along with the official tutorial.<p>I think having a cohesive story for this is table-stakes in a modern programming language.
This is good for clojure, I think. There was a time when lein seemed the preferred tool for clojure projects, but lein seemed to be doing too many different things, and more significantly was not packaged woth clojure. So during that time clojure felt batteries-not-included. With in built tooling, getting into and using clojure should be more easier.
Note to non-Clojurians:<p>Most people just use Leiningen and don't mess with this stuff.<p>This post does not paint a good picture of Clojure development tools, but don't get turned off by it.<p>99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as:<p><pre><code> $ lein uberjar
</code></pre>
I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but I guess Open Source Is Not About Me.
I like Clojure but it is not my primary development language so I am happy to stick with lein. As others here have said, lein is easy to use and gets the job done of creating new projects from a variety of templates, building, and deploying.
Given the general tone of comments here, I thought it worth pointing out the advantages of using deps.edn instead of a Leiningen project:<p>- REPLs start up very slightly quicker
Clojure aficionados love to obesess over this stuff or maybe it's a leftover from their Java days. You come away from Rich Hickey's sermons on the Mount all fired-up with the value of simplicity and before you know it you're knee deep in Clojure's build tools maze - lein, boot, deps.edn, clij, shadow-cljs, tools.deps, tools.build. Clojure blazed the trail for simplicity but as far as build tools are concerned only Go managed to pull it off.