That’s an exaggeration. You’re not entirely wrong, though.

First, it is not called deps.edn, it is called tools.deps.

Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not change the build tool. I have worked with them, and the attitude was always pragmatic > dogmatic.

Where I will agree with you is that some folks in the community took an alpha release of tools.deps and treated it like it was the new lein or boot. It isn’t. It’s different, and as a Clojure programmer of 10+ years I use it in exactly 0 production projects. That said, it improves greatly upon “lein checkouts” by allowing one to refer to git SHAs as versions and do cross-project interactive development.

Fundamentally though I thought the language ecosystem needs stability and consistency. Very many of clojure related tutorials, stack overflow answers are outdated.

Like I mentioned Windows tooling and distribution seems not get much focus.

Emacs, cider, nrepl workflow on Linux is too complex with many moving parts, and very brittle(may be things have improved recently).

A major pain point for me specifically is that on an exception you don't get a live repl, you only get the stack trace of a dead program.

Even some minor inconsistencies lambda positional argument numbers seem to start from 1, than 0, which is where indexes start in all other cases.

Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example?

Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.

Does it matter when all these tools are compatible (on the level of artifacts and distribution repository)?

For the experienced user, it doesn't matter. But for the newcomer, it's one more additional choice to make, and, as the grandparent said, is in sharp contrast to a "batteries included" approach you see in Python. Given that build tooling is one of the more frequent complaints, more fragmentation in this area is undesired.

It's funny that you mentioned Python :) https://wiki.python.org/moin/ConfigurationAndBuildTools

Are you saying that just because there is a choice of configuration build tools and utilities for Python, the argument that there is a standard way of doing things is invalid?

If I want to start a Python project, I `pip install -r requirements.txt` and I can start using it. In Clojure, I need to choose which tool I want to use to perform this simple task, in Python this is standardized. Leiningen, Boot, tools.deps and Maven are all candidates to do this.

There is such de-facto standard in Clojure too. just do `lein`. + even if you choose another build tool, it is:

1) compatible 2) if you're a newcomer, you probably only need a few dependencies, which is configured in the same way as lein's `project.clj`

I mean, I agree that there definitely is a need for better guides for Clojure and defaults, but I don't think that is the reason Clojure is not more popular, and that Python is simpler there. If I encounter Python for the first time, I definitely won't know that I just "pip whatever".

I actually think that Clojure is very popular, given that there is no big Co that pushes it, and that it still doesn't have a widely known killer app. Most other popular(ish) languages are mainly popular due to huge push by a single big corporate sponsor.

But as I said, lein is not distributed with clojure, and installing lein on Windows is not straightforward.

For the most part I’m not sure it matters. What specific problems have you had as a result of fragmentation in clojure project build tools? I don’t much care what the name of the command is: if running it produces an artifact I can depend on and use in my app, then it did the job. Different types of build pipelines have different needs.

For me personally it’s not a problem, but build tooling is a frequent obstacle for newcomers to the language. Fragmentation is the opposite of what we want here.