Clojure and Deps.edn: A basic guide | Hacker News Reader

Clojure and Deps.edn: A basic guide

tomekw.com

138 pointstomekw17 comments

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.

[1] https://www.youtube.com/watch?v=CWjUccpFvrg

Thanks!

Sean also goes into his experience with boot vs tools.cli on the defn podcast https://soundcloud.com/defn-771544745/51-sean-corfield-aka-s...

What I really like about deps.edn is the ability to add git repos and also local projects as deps. Makes forking and testing libraries a charm.

Another wonderful tutorial about using deps.edn that contains additional tips for Emacs -- https://cjohansen.no/tools-deps-figwheel-main-devcards-emacs...

If using lein, there's this: https://github.com/reifyhealth/lein-git-down

EDN is to Clojure as JSON is to JS.

Shame it hasn't similarly transcended its home language because it has a killer feature: https://github.com/edn-format/edn#tagged-elements

FYI, there are edn implementations in many other languages: https://github.com/edn-format/edn/wiki/Implementations

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.

deps support in cursive is excellent, just as an aside. Feels very slick to get a project going.

https://cursive-ide.com/userguide/deps.html

True. This project was created with Cursive :)

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)

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

> 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.

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.

Another working example: https://gitlab.com/tvaughan/kibit-runner and https://clojars.org/tvaughan/kibit-runner (with publish to Clojars)

Reply on news.ycombinator.com