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
 

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
[–] seancorfield@alien.top 1 points 1 year ago (8 children)

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)

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

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.

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

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.

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

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.

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

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.

load more comments (1 replies)
load more comments (4 replies)
load more comments (4 replies)