This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (11)
- # beginners (15)
- # cider (2)
- # cljdoc (36)
- # cljsrn (3)
- # clojure (6)
- # clojure-europe (9)
- # clojurescript (17)
- # conjure (3)
- # deps-new (6)
- # development-containers (1)
- # emacs (3)
- # fulcro (4)
- # gratitude (14)
- # introduce-yourself (2)
- # joker (14)
- # lsp (1)
- # luminus (7)
- # malli (6)
- # polylith (7)
- # releases (1)
- # reveal (3)
- # sql (4)
- # vim (18)
I am personally fine with cljdoc depending on js - but I have typically been on server-side throughout my career so maybe don’t give my opinion too much weight. Maybe @martinklepsch has a different opinion?
So far I’m pretty much liking our use of https://github.com/cljdoc/cljdoc/discussions/460 and https://github.com/cljdoc/cljdoc/issues/459. Small observations: 1. it might be difficult for the interested to see what changes I’ve made to the git issue (so that’s not great) 2. there is no commit churn for changes to a design doc (but see 1). 3. discussion threads are nice 4. small deal, but my personal preference is AsciiDoc and git issues are CommonMark.
I'm curious, why do you think this will fracture the community? Or do you just mean the Clojure CLI /
deps.edn itself (which has been around for close to three years now)?
It's been a strong message from the Clojure team about relying less on packaged artifacts (for many reasons) and relying more on source-based deployment. Datomic Ions is all about source-based deployment, I believe?
tools.build is source-only. Cognitect's
test-runner has always been source-only. That's the natural approach in CLI-land now. I think
lein has a plugin to support git deps?
Aside from helping beginners, I haven't used
lein since... 2015, I think? That was when we switched to
boot at work. Then we switched to the CLI and
deps.edn in 2018.
Taking this to a thread since it's not cljdoc-related now 🙂 We kinda got stuck with
lein. We wanted to extend it, and writing plugins is kind of a pain. That's why we switched to
boot: it was so much easier to extend and write new tasks for.
But we didn't like the fact that Boot has you set up the dependencies programmatically -- we liked that aspect of Leiningen's declarative approach. So we put our deps in EDN files and had a Boot task that read those files and set up dependencies. So it wasn't much of a "hop" when the CLI appeared a few years later with
And we've already switched to
tools.build at work for all our dev/test/CI stuff. And that's why I've also switched several of my OSS projects over to
tools.build and added a
build.clj file that supports the full CI workflow.
Leiningen's fine "in the small" but it doesn't work well with monorepos out of the box, in our experience. It's a nice experience for beginners because it is "batteries included" and it's a fairly simple install on any platform (it even supports
cmd.exe via an old school
.bat file) so kudos, there, definitely. But I really do think the official tooling is better for everyone really 🙂
They have changed, so that doesn't help, and they're going to change again:
-A will stop running
:main-opts so you'll have to use
-M for that.
I think once
-A becomes "run a REPL (only)", it will be easier to remember how to use it.
The deprecation warning for
-A has been around ever since
-M was promoted from "just"
:main-opts to also deps/paths -- but the wording of it changed recently.
I really do wish they'd turned
-R into "run a REPL". It's much more mnemonic:
-X execute a function;
-R run a REPL. Alas we have
-A for "run A repl" 🙂
We did briefly have multi-function execution with
-X but there's an ambiguity in parsing the command-line that made them take it away 😞
Yup, very true about syntax. Erlang is great but it's basically Prolog. Providing alternative syntaxes -- alternative languages sharing a platform's semantics -- is very important (I'm a computer linguist by training/early career). I happen to love Prolog, but I'm weird. I can totally see why having Ruby-syntax on BEAM is a huge draw (I happen to loathe Ruby from a syntax/semantic p.o.v.).
A lot of people are horribly put off by Lisp syntax, even though they are perfectly happy to use any number of Lisp semantics in non-() syntax.
I think Lisp is just beautiful to read (see, I said I'm weird). Ah, yes, that is a downside -- we need sexp-based differs!
Yeah, I think we'll see some sort of aliases-alias feature in
deps.edn/CLI at some point. Folks have been asking about it for years now.
I must admit, I have not looked at babashka at all. I know borkdude is doing amazing work but the official tools do everything I need (even though I want them to do more).
You could point at babashka and say it's "fragmenting the community" but I don't think that's any more true than accusing the Clojure CLI of doing so 🙂
Since we are happily off topic here, I moved to
deps.edn ages ago and prefer it. I liked lein, but personally found it too mysterious in the details of what it did, and if I wanted to make it do something else, I did not find that simple. These days I'm using babashka tasks in front of deps.edn.
Back in my java days I used maven and that was certainly the case with it. Lein felt a little bit like that but not so extreme.
But really I see it as a personal preference... and have no problemo with lein enthusiasts.
Hmm, that inspires me to put "beginner testing" in my brain to come up with a blog post...
Yeah, and even as a non-beginner, that whole http://gitpod.io/vscode online experience is pretty amazing!