No commits on GitHub since 2022, the slack channel is dead silent, and it seems everyone here recommends deps.edn. Is Leiningen worth using in 2023 or should I jump ship?
No commits on GitHub since 2022, the slack channel is dead silent, and it seems everyone here recommends deps.edn. Is Leiningen worth using in 2023 or should I jump ship?
It may sound bad, but I agree. The split between tools deps and lein just creates confusion and friction with newcomers, who start using clojure with deps, but inevitably run into a library that’s built with lein. Also, mixing lein dependencies into a tools deps project breaks things like overriding transitive dependencies.
I know tools.deps and Leiningen/Maven have subtly different dependency resolution logic, but is this a problem in practice? I’ve never run into myself, and surely its trivially fixed by making the dependencies explicit.
Apologies, I don’t have a lot of time to dig into this further and my memory has faded since I last ran into this, but I remember at least two issues:
when I want to use a
:git/url
version of a library that’s built with lein, I have to use:deps/manifest :deps
and I believe that there’s basically no way forclj
to know about the dependencies of the library that way (keep in mind thatpom.xml
is not usually checked into git for these libraries). The way I used this was to override thefi.metosin/reitit-openapi
transitive sub-module offi.metosin/reitit
(which I got from clojars), so I already had all the other dependencies in the classpath.I had a private fork of a library that was built with lein and was relying on build steps that could have been solved
:deps/prep-lib
if the lib was using tools depsThe reasons I had to use git refs and private forks are fixed now in the upstream of the libraries so I don’t have my workarounds anymore.