this post was submitted on 18 Oct 2023
1 points (100.0% liked)

Lisp

53 readers
3 users here now

founded 1 year ago
MODERATORS
rglullis
defmacro
1
Is Leiningen dead? (alien.top)
submitted 1 year ago by BetGlass7087@alien.top to c/lisp
42 comments fedilink hide all child comments
 

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?

​

you are viewing a single comment's thread
view the rest of the comments
[–] lgstein@alien.top 1 points 1 year ago (1 children)

Unforunately not

[–] fszdg@alien.top 1 points 1 year ago (1 children)

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.

[–] weavejester@alien.top 1 points 1 year ago (1 children)

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.

[–] fszdg@alien.top 1 points 1 year ago

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 for clj to know about the dependencies of the library that way (keep in mind that pom.xml is not usually checked into git for these libraries). The way I used this was to override the fi.metosin/reitit-openapi transitive sub-module of fi.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 deps

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