Lisp

53 readers

3 users here now

founded 1 year ago

MODERATORS

rglullis

defmacro

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

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

I still use Leiningen for libraries, as it currently has better jar generation/deployment functionality than the deps.edn ecosystem.

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

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

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-data in 0.9.6 is certainly a step forward.

[–] 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.

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

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:

gnl/build.simple: tools.build's missing piece – install, sign and deploy libraries easily and securely like with Leiningen

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

Ah, interesting! I see you're shelling out to Maven for deployment?

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

Yup, seemed like the most straightforward solution. But other than installing it once and writing a basic ~/.m2/settings.xml to 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.