
Clojure and Deps.edn: A basic guide - tomekw
https://tomekw.com/clojure-deps-edn-a-basic-guide/
======
geospeck
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](https://www.youtube.com/watch?v=CWjUccpFvrg)

~~~
millettjon
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...](https://soundcloud.com/defn-771544745/51-sean-corfield-aka-
seancorfield)

------
dimovich
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...](https://cjohansen.no/tools-deps-figwheel-main-devcards-emacs/)

~~~
elwell
If using lein, there's this: [https://github.com/reifyhealth/lein-git-
down](https://github.com/reifyhealth/lein-git-down)

------
frou_dh
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](https://github.com/edn-format/edn#tagged-elements)

~~~
puredanger
FYI, there are edn implementations in many other languages:
[https://github.com/edn-
format/edn/wiki/Implementations](https://github.com/edn-
format/edn/wiki/Implementations)

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

------
danpeddle
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](https://cursive-
ide.com/userguide/deps.html)

~~~
tomekw
True. This project was created with Cursive :)

------
geokon
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)

~~~
puredanger
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](https://github.com/clojure/tools.deps.alpha/wiki/Tools)

~~~
geokon
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?

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

