In addition to the post I will add here a nice video[1] that was recently uploaded
from the very well known in Clojure community Sean Corfield which demonstrates
the functionality and power of Deps.edn.
None of which work very well, and most are completely broken. The only ones that completely work are CLJ/CLJS/CLJR's internal implementations, so you have to pull in all of Clojure just to read EDN from java, for example.
Transit is a much better choice here, but even that tends to be a bit non-idiomatic in languages like Python. That's not really the fault of Transit though, languages are just too different to have a single communication protocol work flawlessly between them all.
thanks for the guide! I've sorta been avoiding dipping my toes into deps.edn. Maybe I missed it, but this doesn't really seem to illustrate any advantage over lein
now you have to hunt down extensions/plugins to do testing and make uberjars, cobble it all together yourself and then hope they remain maintained going forward
what's the benefit? you can make wacky nonstandard directory layouts? I feel like I'm missing the motivation or maybe my problems are too simple. that said it does seem like a nice low level tool (ie. maybe lein could be implemented in terms of deps.edn)
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).
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.
[1] https://www.youtube.com/watch?v=CWjUccpFvrg