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?
Unforunately not
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/urlversion of a library that’s built with lein, I have to use:deps/manifest :depsand I believe that there’s basically no way forcljto know about the dependencies of the library that way (keep in mind thatpom.xmlis not usually checked into git for these libraries). The way I used this was to override thefi.metosin/reitit-openapitransitive 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-libif 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.