Build tools like lein or Maven attempt to build a "declarative" definition of a project and then apply a set of plugins to that model using an implicit lifecycle. In reality, simple projects don't need that complexity and complicated projects only match 80% to either the lifecycle or the plugins available, so you end up wedging imperative things onto the build, hunting down obscure plugins, or hacking your own. Other build tools (like boot, or even Ant) acknowledge that builds are actually programs built from similar tasks.

deps was designed to find a sweet spot in the middle of this with deps defined as data, aliases capturing program executions as data, but builds as programs. As such, the scope is drastically narrowed in deps to just a) building classpaths (by resolving dependency graphs) and b) launching programs.

As such, this tends to be a dramatically simpler model to start with (your initial deps.edn can be empty), and a model that is easy to understand as you scale up. I think there is more to do in how we model "tools" (esp tools shared across projects) and program composites, but nothing prevents you from building these yourself if needed (as you have the full power of Clojure at your disposal).

You can find a pretty comprehensive list of deps.edn tools at https://github.com/clojure/tools.deps.alpha/wiki/Tools

Thanks for that. I've read up a bit more and I see how you're trying to build a more easily extensible ecosystem. Hope it all get easier to use with time.

I read up a bit more about how to setup a project and the github/local/remote library stuff is very powerful (and not as smooth to setup in lein). I'm wondering about your workflow and how you are mixing and matching local libraries with github and maven/clojar ones. Do you have a separate deps.edn file for local development that point to local "fluid" libraries and then you have periodic freezes where you substitute it for a public deps.edn file and then push it to github/maven?

I think that while leiningen does a lot of what tools.deps/deps.edn and the CLI tools do, the reverse is not true.

tools.deps/deps.edn is about building a classpath to run a clojure process. The clojure CLI tools has some additional machinery for starting a simple REPL. That's it.

What this allows is a potentially more composable ecosystem, where instead of having every new build tool implement a way of declaring dependencies and building a classpath, they could instead use tools.deps + deps.edn.

It also has a slightly different feature set, allowing local dirs and remote git repos to act as first-class deps.

Lein and boot are incumbent, and have legacy projects to think about, so they can't go about just adopting deps.edn + tools.deps without breaking things. So at the moment, things are a bit fragmented. C'est la vie.

> cobble it all together yourself and then hope they remain maintained going forward

That is one benefit of deps.end over lein... deps.edn is language supported, lein is third party.

You are right. Today I have discovered https://github.com/seancorfield/dot-clojure which tries to put everything in one place.