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.
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.
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.
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.
You no longer need local Maven repo, because tools.deps supports local dependencies, you can basically just depend on local folders. It also can depend on git repos.
That's just a matter of man power. Things take time, this sort of tooling wasn't the priority. The community was able to easily take over that space, and relying on Maven was a great way to start off.
Pip isn't even the recommended one to use anymore, slowly being superseded by Pipenv, yet you also have Poetry and conda and to package things you still need setup tools and you have to use twine to submit wheels to pypi, etc. And I still see a lot of guides telling you to use easyinstall still.
In Clojure, you had Maven first as the de facto, then Leiningen became de facto, and now you have an official one with tools.deps as the new de facto.
Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python.
There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job.
Also when exeptions occur clojure does not give an interactive repl like other lisps.