This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-06
Channels
- # announcements (14)
- # babashka (12)
- # beginners (61)
- # biff (2)
- # calva (16)
- # clj-kondo (22)
- # cljdoc (7)
- # clojure (131)
- # clojure-europe (52)
- # clojure-losangeles (9)
- # clojure-norway (54)
- # clojure-spec (5)
- # clojure-uk (4)
- # clojurescript (18)
- # cursive (14)
- # datomic (19)
- # deps-new (14)
- # emacs (8)
- # events (7)
- # fulcro (6)
- # graphql (3)
- # hyperfiddle (42)
- # instaparse (5)
- # lsp (10)
- # malli (21)
- # nbb (1)
- # off-topic (3)
- # pathom (3)
- # polylith (7)
- # reagent (14)
- # releases (2)
may I ask, what is the motive in general for replacing leinegen?
I'd see the matter more as picking lein or something else (usually deps and CLI) from a menu. A lot of people&teams are happy with lein so this one isn't going anywhere in the short term and I don't see it being really replaced (at least for Clojure/JVM, I have the impression that more recent FE/Cljs tooling tend to default more to deps and CLI). Reasons to prefer deps & CLI in my own words: • more flexible / malleable / extensible in particular if you want / need more control to customise your setup • designed, shipped and approved by the same people who built Clojure, which usually means good stuff guaranteed 🙂
The intent of the Clojure tools (CLI, deps, build) was not to create a like for like replacement of Leiningen, as I understand it. So it's not designed as a replacement, but an alternative approach The intent was to provide a built-in set of tools to use with the Clojure CLI to run Clojure, which along with community libraries and tools can provide some or all the features that happen to be in Leiningen (and more) See this article for background https://clojure.org/guides/deps_and_cli And my alias definitions that provide a common set of tasks https://practical.li/clojure/clojure-cli/
This page talks about the different tools and approaches and provides some history https://clojure-doc.org/articles/tutorials/getting_started/
There's also always been a "guiding principle" that core -- Clojure itself + Contrib libraries -- should not depend on 3rd party Clojure libraries. That seemed to be extended to Datomic and Ions and so core came up with a solution for "running Clojure" for that tooling -- which evolved into the CLI / deps.edn
.
This is kind of an odd channel to ask this question, BTW, since this is for the deps-new
library. @U043HLWSYUQ can you clarify your intent behind asking the Q in this channel as opposed to, say, #C6QH853H8 or #C02B5GHQWP4?
Perhaps some history on lein new
through to deps-new
?
Originally, new
was a plugin for Leiningen that got incorporated into the main tool. When Boot appeared, it had no equivalent so I ported Leiningen's new
over to Boot (as the boot-new
library). When the CLI appeared, it also had no equivalent so I ported boot-new
to clj-new
. All of lein new
, boot new
, and then clj-new
work essentially the same way: they all support Leiningen templates, boot-new
and clj-new
both support Boot templates as well, and clj-new
also supports CLI / deps.edn
templates (but there aren't very many of those).
Writing templates for those new
tools always required writing code to copy files etc, so when tools.build
appeared, with file/directory copying and git support etc, it seemed like a good opportunity to provide an all-new project creation library based on a more declarative approach. Hence deps-new
. I believe it is easier to write new templates with deps-new
and it is more in keeping with the data-first approach of Clojure in general.
Thanks for all the helpful responses! This is all super-helpful. Clearly I'll have to spend a couple days study to understand all this. I started learning Clojure last year with "Web Development with Clojure, Third Edition" which used Leinengen and Luminus. But it seems most of the technologies used are no longer state-of-the-art.
The same authors have now produced the Kit "framework" as the next-gen, modular approach to Luminus, and Kit uses the CLI / deps.edn
.
yes but no book last-time I checked
One nice thing about Clojure is that old libraries generally continue to work on newer versions of Clojure and the JDK so you don't have to change libraries if you don't want to. I'm one of those masochists that always likes to be on the bleeding edge -- hence running Clojure alphas in production 🙂
I agree with that TBH. It's so painful at work where we're not allowed to update anything unless it has a CVE against it
Our production systems: • clojureCLI Clojure CLI version 1.11.1.1386 • clojureVersion 1.12.0-alpha4 • javaCLI openjdk version "20.0.1" 2023-04-18 • javaVersion 20.0.1 • jvmVersion 20.0.1+9 😁
I mean I guess if you have a test driven-approach why not?
The intent of the Clojure tools (CLI, deps, build) was not to create a like for like replacement of Leiningen, as I understand it. So it's not designed as a replacement, but an alternative approach The intent was to provide a built-in set of tools to use with the Clojure CLI to run Clojure, which along with community libraries and tools can provide some or all the features that happen to be in Leiningen (and more) See this article for background https://clojure.org/guides/deps_and_cli And my alias definitions that provide a common set of tasks https://practical.li/clojure/clojure-cli/