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?
I don’t think Leiningen is dead but I think Boot is
My suggestion would be to start learning deps.edn though
alive.
And it works!
No idea, haven’t used it in ages.
Very much still alive - we find it simpler than deps.edn and related tools for many tasks. Learn both.
In the Clojure sense, Leiningen is definitely easier (but it is not simpler tooling).
We should stop repeating this line - it is simpler but not easier… or similar variant. It is becoming extremely cringe.
Whenever there’s some criticism we paste this line
It’s core to Clojure’s design principles tho’. If you think it’s “cringe” then maybe Clojure isn’t for you? Seriously, the mantra of Clojure’s design is small, simple pieces, composed together. Easy = familiar. Leiningen is “easy” because it’s like build tools in other languages. Clojure CLI /
deps.ednis simple because it’s designed specifically for composition. It’s a really important distinction.
(:
Repository was relocated to codeberg. Leiningen is still pretty much alive
Okay that is somewhat reassuring.
So, where do most folks get support? On Slack, deps.edn questions are answered quickly, whereas lein questions tend to linger. I got stuck trying to get git deps to work, and it’s hard to ignore that many Clojure projects on GitHub have moved away from lein. It’s left me wondering if I am falling behind with the modern Clojure ecosystem
To be honest, I have no idea. Leiningen has a IRC channel, but I’m not sure it’s the right place to ask for support
should be hagelcode
Cool! Now can we get a proper transitive deps so there is no more reason to not rely on lein long term? 😅
Can you be a bit more specific about what “transitive deps” are supported by Leiningen but not tools.deps?
Do you mean BOM support in POMs? Vote on that here: https://ask.clojure.org/index.php/10892/add-support-for-bom-bill-of-materials-dependencies – there’s already a JIRA ticket and some initial work done.
I think it would be a terrible loss if it did, though it’s getting harder to compete with deps’ blessed status as the developers’ baby, even if I find the experience of the latter drastically worse.
I wish.
I personally use Leiningen. Still not proficient with this deps.edn stuff. And it requires you to do lots of things from scratch. YAML vibes. I believe there are helper binaries but there are many with different features and you need to choose
lein just works and stable but deps and tools is newer and the usage within the community is about 50/50.
I fear the new development of plugins etc may not happen for lein
In my limited experience, writing leingen plugins was annoying. I don’t miss those days.
That was why we switched from Leiningen to Boot in 2015.
And then we switched from Boot to CLI/
deps.ednin 2018 and jumped ontools.buildas soon as it appeared.
Perhaps it has reached perfection.
I prefer deps.edn for new projects, but Leiningen is still useful and alive, projects like https://github.com/babashka/babashka still use it.
It is curious because babashka itself uses ‘bb.edn’ as a means of configuring the dependencies of a project.
Babashka also made possible ‘lein2deps’ and ‘neil’ two commands that help with the definition of a deps.edn.
One of the babashka maintainers here. bb.edn is for projects that run on babashka not for standard JVM projects. Since babashka itself is a standard JVM project we use tools.deps/lein as usual.
Don’t think there is a good reason to keep lein but one of the reasons we keep it is that it all “just works” and we would not like to change things just for the sake of it. “Don’t change anything unless its broken” :)
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 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.
-
I still use Leiningen for libraries, as it currently has better jar generation/deployment functionality than the deps.edn ecosystem.
What’s missing at this point? (comparing Leiningen to tools.deps + tools.build + deps-deploy – which is the stack I’ve switched all my library projects over to)
tools.build lacks support for adding project descriptions, URLs and licenses to pom files. Or more accurately, it expects that you maintain a pom file in source control, which it then updates and edits for you. By contrast, Leiningen generates one from scratch from the project file.
So in Leiningen you have a user generated project file which you keep in source control, and a machine generated pom file you keep out of source control. In tools.deps, the pom file is intended to be both user and machine edited, an approach I really don’t like.
deps-deploy insists on getting the GPG signing password itself, rather than relying on gpg-agent to manage authentication. This means that if I want to deploy a signed package with deps-deploy, I need to enter my password in every time. Leiningen defers this to gpg-agent, which allows the OS to handle authentication.
Shameless plug of a recent tiny project that remedies precisely those points – incl. secure credentials handling for signing and deployment – without needing to touch pom.xml, write glue code or use multiple tools for the basics:
Ah, interesting! I see you’re shelling out to Maven for deployment?
Yup, seemed like the most straightforward solution. But other than installing it once and writing a basic
~/.m2/settings.xmlto point it to the environment for repo credentials, you should never have to think about it again.If all you need from Leiningen is build/install/deploy a library jar, build.simple should have you covered. I’m dogfooding it in my other recent project Playback – so far so good.
tools. Build lacks support for adding project descriptions, URLs and licenses to pom files
No, it specifically supports this now.
it expects that you maintain a pom file in source control
Nope. That’s never been true. It’s always been optional.
GPG
Fair enough. I haven’t signed JARs for years and found the whole gpg-agent thing to be a giant mess on both Mac and Windows (is it even possible on Windows?). Pretty much everyone has given up on signing at this point, I think? Clojars certainly doesn’t care any more. In other words, this feels like a straw man / moot argument.
Build lacks support for adding project descriptions, URLs and licenses to pom files
No, it specifically supports this now.
That’s good to hear. It looks like that functionality was only added in 2 weeks ago, though.
it expects that you maintain a pom file in source control
Nope. That’s never been true. It’s always been optional.
It’s possible I misinterpreted Alex Miller’s response, but when I asked previously about how to support extra pom data (before
:pom-data), that was the answer I was given: “We don’t support lots of elements as we can sync from a source pom[. ]So write the pom template with whatever you need and sync that”Pretty much everyone has given up on signing at this point, I think? Clojars certainly doesn’t care any more. In other words, this feels like a straw man / moot argument.
I still sign all my packages. I mean, why not? I already have it all set up. It may be that I’m in the minority, but removing signatures would feel like a step backward.
I’m not sure why you consider this a “straw man / moot argument”. Note that I’m not advocating people use Leiningen, I’m just stating the reasons I still use Leiningen.
You interpreted my response correctly at the time … my mind was changed. :)
Nobody anywhere checks the signature (and if you try using the tools provided, you’ll find out why), so signatures are largely security theater in maven world. This is bad, and we should do better. Hoping to eventually have time to work more on this, and have had some sidebars with Phil H about it.
Pretty much everyone has given up on signing at this point, I think?
I sign all my packages (and also my release commits and tags) – the infrastructure and tools to support easy and thorough artifact verification may not exist at this point, but I’d rather see us collectively push things in that direction than give up on supply chain security altogether.
Nope. That’s never been true. It’s always been optional.
Maybe technically optional, but practically not so much – if you wanted to edit any metadata like project description, licenses, etc., you needed a pom.xml template file. The recent
:pom-datain 0.9.6 is certainly a step forward.
We use Leiningen all the time on a very big project. Reliable and tons of useful features.