both tools are excellent, leiningen was the only option for several years, and played a pivotal role in clojures growth and everybody loved it, and still do today, i presume a lot of seasoned clojurists then moved to tools deps because it’s fundamentally simpler in the rich hickey sense, but not easy like leiningen. But for all my uses cases, i’d be completely happy with either one. There are very slight differences in capabilities (project.clj is turing complete, whereas deps.edn is not but build.clj is, dealing with git sha dependencies , etc, etc), but i doubt that’s what your question is about

Jack in always "just works" for me. Can you provide a bit more detail? But, yeah, Leiningen is fine if that works for you. We switched from leiningen to boot in 2015 and to the CLI in 2018 because that's what worked for us better at work - we have a huge monorepo with nearly 200 deps.edn files at this point.

This article talks about the two tools https://clojure-doc.org/articles/tutorials/getting_started/

leiningen does too much. it has a bunch of really sensible defaults but it also bundles with it a multitude of other features and choices that are really annoying to work around. for example, lein test is great cuz it "just works" and is how 90% of lein projects are tested. however, it monkey-patches clojure.test, it relies on a built-in test runner that can't be swapped out, and everyone expects lein test to work.

I prefer Clojure CLI. I must say I haven't faced the same issues you have. It always "just works" for me OOTB, cider-jack-in works fine, it starts faster, aliases are more composable. It requires slightly more "manual control" but I haven't had issues. Did it give you problems with work projects or in general?

I've used Clojure CLI for several years and prefer the flexibility provided by this approach. I enjoy the data approach of the deps.edn configuration and being able to add community tools via aliases, e.g. https://practical.li/clojure/clojure-cli/practicalli-config/ To enhance the usability and consistency of projects, I use https://practical.li/engineering-playbook/build-tool/make/, e.g make repl, make uberjar, make test, make test-watch. I use these tasks for all the project I work on so they can be used in the same way. Make is build tool agnostic, so can be used with any tooling. A similar thing can be written and maintained using Babashka script. I assume the :dev alias is used to run code from a custom user namespace, e.g. dev/user.clj, loading Clojure code at REPL startup. If the alias is not included then that code will not be loaded. The custom user namespace can also be used by Leiningen, so can trip up both tools if badly maintained. I https://practical.li/clojure/clojure-cli/repl-startup/, e.g. Portal for data inspection, mulog publisher (tapping into portal), etc https://practical.li/spacemacs/clojure-development/project-configuration/ may help with cider jack-in, ensuring a consistent command (alias) is used. Tying the Emacs universal argument, C-u (`SPU u` in Spacemacs) allows for editing the command first.

The "sensible defaults" is what is lacking IMO. I called it "standards" because, like mentioned here, more manual work = more unexpected work. Having a makefile to provide how to make repl which I've seen in several projects before does make it a lot easier. In the case I was referring to :dev is an alias and it does require and move to user.clj, but it immediately quit the repl for me. I decided to go to sleep :) I run into clojure cli mostly outside work. At my workplace leiningen is the standard tool. This is probably another reason I find it harder to use, but the comments here suggest it's a me problem 😬

#C03KCV7TM6F is a good entrypoint for sensible defaults

Not exactly a you problem, just a habits problem. There are people who still don't like clojure cli. It's a valid position

To be clear: clj-new (and deps-new) are tools to create new projects. They are not "libraries that do things on behalf of users". The projects they generate use plain ol' tools.build.

The way write-pom works in tools.build is that you can provide a source pom.xml file for it to work from and it will use that and add <dependencies> etc to it. You'll need that for a lot more than just <licenses>. See https://github.com/seancorfield/deps-new/blob/develop/resources/org/corfield/new/lib/root/pom.xml for an example of lots of pieces of pom.xml that you might want to provide yourself.

What you might want to Ask for is to provide an example of using a source pom.xml file in the tools.build guide.

Which reminds me that https://clojure-doc.org/articles/cookbooks/cli_build_projects/ doesn't talk about this so I'll create a GH issue on that repo to add a new section about that.

Clojure core members deny and gaslight any criticism of their failures. “I love Clojure the language but I’ve never seen a more fragmented ecosystem. There seems to be a pattern in the language of “a problem emerges > a community solution gains traction > Cognitect develops their own solution but its weird and undocumented”, like deps.edn over leiningen, spec over malli, pedestal over ring, etc. Many prominent clojurists recommend deps.edn over leiningen and socket repl over nrepl, but I’ve seen very little guidance on how either actually work or how to use them. Spec seems kind of weird and not well thought out either. And Clojure CLI tools also seem like a total shitshow compared to go or rust’s tooling. As a result working with Clojure feels puzzling and unpleasant, and I feel hesitant to use any community library or project in the language.”

> spec over malli, pedestal over ring I am confused. Morning.

Hard to take a hn reply guy that seriously when the criticism doesn't even bother to check whether spec predates malli or not - the implication seems to be that malli should be preferred to spec even though the latter came first? Better documentation is always a good thing, no one will argue against that. But I simply don't agree with the contention that multiple libraries serving similar purposes is a sign of an unhealthy or failing ecosystem. Is Python unhealthy because both Flask and Django exist? Is JS unhealthy because both React and Svelte exist?

It's also worth noting that pretty much the only time anyone complains about multiple libraries or tools for the "same" thing is when the core team creates one of those "competitors". No one complains about multiple near-identical-purpose libraries from the community :face_with_rolling_eyes:

And the "pedestal over ring" comment is laughable, especially when coupled with "undocumented": http://pedestal.io/ looks like pretty good documentation to me and Pedestal is built on top of Ring (as are many other web libraries) -- and has been community-maintained for years at this point.

(besides, we've all read the HN complaints... 🙂 )

> Hard to take a hn reply guy that seriously when the criticism doesn't even bother to check whether spec predates malli or not The HN post probably meant spec over prismatic schema