More and more introductory material is appearing these days featuring deps.edn but given there was a decade of Leiningen usage out there before deps.edn even appeared, the current state of affairs shouldn't surprise anyone.
As for more than one system, lots of languages have that situation: consider make -> ant -> maven -> gradle etc.
> The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool.
This seems like a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it.
My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them.
I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal.
To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head. And it has really nice documentation with tons of examples.
It just always felt like I was running into things that felt basic and the docs didn't have an answer for them. I would see so many elaborate deps.edn files in people's configs and when I tried to look up how they worked I couldn't find anything.
That depends how you define your build targets (called aliases) in deps.edn. And there is also -T to call (public) functions in a namespace (file/program), e.g. when using build.clj - that's for building your jar.
-X calls a function that you can define using :exec-fn, :exec-args has it's arguments (usually a map) -M calls the main function ('executes a program', if you will), it's 'normal' (command-line) arguments are passed using :main-opts
And btw. `clj` is just a wrapper around `clojure` that runs `clojure` in rlwrap. No need to use this if you do not use the REPL.
Here is a (big) template I've just finished yesterday: deps.edn: https://github.com/Release-Candidate/Clojure-Template/blob/m...
and it's usage: https://github.com/Release-Candidate/Clojure-Template#build-...
build.clj - build a jar and run mkdocs https://github.com/Release-Candidate/Clojure-Template/blob/m...
My new project deps file is always literally "{}". I love that that's all I need to do to start doing stuff. I add a couple libraries as needed. Maybe at some point an alias or two.
In particular cloning their clojure-deps-edn [2] as my ~/.clojure folder gives me ready made aliases for different kinds of repls, tools like reveal etc.
This, plus polylith [3] architecture has finally allowed me to start working in clojure and not get lost in configuration confusion.
[1] https://practical.li/clojure/clojure-cli/projects/add-librar...
Deps is well documented.
The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool.
> socket repl over nrepl
I personally use Calva (VSCode) which just starts an nrepl based on deps.edn. When writing babashka scripts I start the repl manually and connect to it. Very pleasant experience so far.
> Spec seems kind of weird and not well thought out either.
I didn't like it at first, but once I got that everything is bottom up I had an AHA moment. Function specs and instrumentation are very powerful. Conform is basically a parser, which can give you a lot of leverage.
What bothers me about spec is that it is still not released though.