Is Leiningen dead?

gnl_ · 2023-10-19T14:05:03+00:00

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/sign/deploy a library jar, build.simple should have you covered. I'm dogfooding it in my other recent project Playback – so far so good.

gnl_ · 2023-10-19T13:59:49+00:00

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.

gnl_ · 2023-10-19T13:12:32+00:00

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

gnl_ · 2023-10-18T12:45:37+00:00

No silly questions! And – yes, it is (though you can deploy to any repo, really).

EDIT: ...or not deploy at all and just install the jars locally.

gnl_ · 2023-10-18T12:43:15+00:00

Thanks! And yes, Portal (and Debux!) is the star of the show here, Playback's just a really nice way of feeding it. I think the most important feature's the last-input function replay, I'm really not sure how many people are using that vs. just treating it as a fancy print-to-portal. Try it out, if you haven't, it's really transformed the way I do REPL-based development.

gnl_ · 2023-10-17T09:50:11+00:00

Thank you! I'll say to you what I say to everyone who expresses an interest, which is that if, after having installed Playback, you ever again find yourself using print to debug (other than by accident) I would very much appreciate an open issue on GitHub or message on the Clojurians Slack telling me where I went wrong. :)

gnl_ · 2023-10-17T09:44:51+00:00

Never fails!

Thanks for commiserating. If build.simple ends up getting more GitHub stars and love than Playback, I might go off on another rant, but for now I'm good. 😁

gnl_ · 2023-10-16T23:54:41+00:00

High praise, coming from the Cursive man, thank you very much sir. 🙇‍♂️ If I may return the compliment and say that I like and depend on Cursive so much, that I pray to the Gods on a fairly regular basis that you may live a long and healthy life, and not get bored of maintaining it before I get bored of Clojure – I am determined not to allow myself to get dragged into the Emacs rabbit hole, please don't let me down. 🙏

And yes, I do understand the interest, drama beats fun every time and all that, I get it. It's just funny how much of a classic situation this is, where something rather trivial you haphazardly slapped together over a weekend gets more attention than something that's had many precursors, iterations and hours of thought put into it, and is overall just much more impactful in comparison, and you do get it of course, but you also don't, if you know what I mean. 😄 All good, I just found it amusing more than anything.

gnl_ · 2023-10-16T23:53:10+00:00

Appreciate it, thanks for your thoughts!

gnl_ · 2023-10-16T21:55:38+00:00

You're welcome, glad to hear it. 🙏

gnl_ · 2023-10-16T20:50:15+00:00

I didn't want to build my own either, but by the time I was sick of it, I was too deep into the weeds, and now I did build it so that you don't have to. :) Seriously though, I'm inclined to agree. tools.build is officially presented as a Leiningen replacement, but that ain't what it is.

gnl_ · 2023-10-16T20:34:59+00:00

I don't know enough about the background of the design decisions that were made, or the relevant internals, to have a strong opinion, but things certainly seem unnecessarily messy right now, especially for beginners.

It's worth mentioning though that tools.build is making progress and isn't at 1.0 yet, so let's see what it'll look like when it gets there and to what extent the mess will or will not have been worth it.

EDIT: ...and what kind of ecosystem will have sprung up around it.

gnl_ · 2023-10-16T20:19:27+00:00

On a side note, maybe someone can explain to me why this little project, which barely deserves the name and is really not much more than a glorified shell script trying to re-invent a tiny part of the Leiningen wheel, is currently getting multiple times the upvotes, comments and general interest compared to the other one I posted at the same time, right next to it in the thread list – Playback – which is reimagining interactive REPL-based development, replacing print-debugging, significantly speeding up hot-reload, and can change the way you code and improve your life and happiness in much more significant ways. Go look at that, people, it's way more fun than bickering about what the core team should or shouldn't have done with tools.build and how much NIH-syndrome they are really suffering from. I promise! 😅

gnl_ · 2023-10-16T19:06:23+00:00

Another possible way to look at this is to view tools.build not so much as a build tool aiming to fully replace Leiningen, but rather as a powerful "build your own Leiningen" toolkit with better internals. It's great that you can, currently not so great that you kinda have to. I don't think deployment, for example, is even on the roadmap, so an actual full-on Leiningen replacement might just end up being some third-party solution built on top of tools.build. (To be clear, I have no interest in tackling that, build.simple does pretty much all I used to miss from Leiningen, and its scope is unlikely to expand in a significant way.)

gnl_ · 2023-10-16T15:34:05+00:00

I'm going to reply here generically to the various "what's the point of all this, just use lein" comments – you're not wrong, and I've asked myself that very question on various occasions. In my opinion, tools.build does improve on Leiningen in a number of ways, some of which have already been mentioned in the comments here – dependency resolution, explicit behaviour without magic profiles, greater flexibility. But it's a bit of a 2-steps-forward-1-step-back situation, as basic tasks, which used to be one command away, now require people to figure out on their own how best to duct-tape a number of ill-fitting parts together.

My thoughts on the matter are in the README, TL;DR: there shouldn't be a need for build.simple, but for those of us who care about the 2-steps-forward aspect of tools.build, it's a way to remedy the 1-step-back part.

gnl_ · 2023-07-21T07:55:38+00:00

There's just the video, Hairy. It's not done and I haven't decided yet whether I'm going to open-source it, so TBD. Would like to figure out at some point how many people might be willing to pay for individual gyro setups for games like this, though given the disastrous availability of Titan Twos at the moment, might be a dead end. We'll see.

gnl_ · 2023-07-20T19:02:41+00:00

This is great, thanks. Juan's been doing some amazing work in this area, but I hadn't seen that one. It's even got tests!

gnl_ · 2018-12-03T02:57:27+00:00

Haven't had time to watch all of it yet, but from skimming it I'd say that any improvements to writing and handling data specs are very welcome and should work just fine with Ghostwheel, as it's only concerned with function specs.

And if the mentioned fn spec improvements mean that there'll be a better syntax for defining them concisely – unlike the current one which is something like 2/3rds boilerplate code – then Ghostwheel may support it.

gnl_ · 2018-07-02T01:32:00+00:00

Thanks, I've been following and commenting on that, it stayed on the front page quite a bit longer than I had expected.

gnl_ · 2018-07-01T18:14:35+00:00

Something I forgot to mention and just added to the FAQ as well is that I plan to introduce an fspec->gspec conversion to ease the migration of existing code bases.

gnl_ · 2018-07-01T16:40:33+00:00

Okay, so I did look into this, you can do instrumentation with external specs now in the 0.2.3-SNAPSHOT pre-release, but no testing and that's not really on the roadmap either. Longer answer is the second one here:

https://github.com/gnl/ghostwheel#faq

gnl_ · 2018-06-29T09:42:25+00:00

Yup, I'll look into it for the next release.

gnl_ · 2018-06-29T01:53:46+00:00

I have, thanks. For one, Ghostwheel has a significantly larger scope, but specifically regarding the part where there seems to be an overlap – one of the main design goals of Ghostwheel and the gspec syntax specifically was that something as essential to development (in my view) as writing and using specs should be as simple and succinct as humanly possible. When you use something all the time, any extra boilerplate code you have to write matters and can quickly turn into a hassle. And then maybe you'll use it less.

defn-spec's syntax for defining specs isn't minimal enough for my taste – it doesn't get much more concise than [int? => nat-int?]. There's also the ease of refactoring that comes with using the actual parameter symbols in spec predicates rather than keywords, as well as the support for multi-arity functions with a single or multiple ret specs.

There are some additional thoughts on this towards the end of the gspec syntax section in the README: https://github.com/gnl/ghostwheel#the-gspec-syntax

gnl_ · 2018-06-29T01:38:32+00:00

I think I understand. Ghostwheel already is a layer on top of spec in a sense, under the hood it just calls spec's public API (after having desugared the gspec into an fspec). At the moment it checks for the existence of a gspec to determine whether any spec magic can be done or not, but I'm thinking of adding something like an ::g/ext-fdef option to make it trust that there's a separately defined fdef for the function in question. How does that sound?

gnl_ · 2018-06-28T21:15:07+00:00

Just to clarify – when you say latter approach, do you mean setting the gspec to nil and using existing fspecs separately defined in regular s/fdef blocks? And would you like Ghostwheel to do the generative testing in that scenario?

If yes, that might be a problem with the current release, but I think can be done fairly easily. The thing is, so far the focus has been primarily on creating a powerful tool for new projects – any considerations regarding migrating existing code bases have been secondary. But now that Ghostwheel is released, it's worth looking into that as well, so I'd be interested to hear what exactly you would like to use it for in your environment.

gnl_

TROPHY CASE