Hacker News Reader

Comment by dgb23 | Hacker News Reader

> deps.edn

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.

View on HN

> 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.

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 knowing only the name of a package I want to use. And it has really nice documentation with tons of examples.

https://github.com/jwiegley/use-package

> 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.

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.

I have found practical.li [1] to be an excellent source of information.

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...

[2] https://github.com/practicalli/clojure-deps-edn

[3] https://polylith.gitbook.io/poly/

The C language is extremely well-documented. It's still helpful to see other people's C code to understand common/useful patterns.

I don't know. I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them? When do I use each? What's the -r flag do and how do I use it? How do I update my dependencies? How do I build a jar and deploy it?

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.

> I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them?

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...

Deps.edn is a bit strange but build.Clj was the thing that really felt like Setup.py writing in 2010

Deps may be well documented, but lots of introductory material seems to use lein. Having two systems is more confusing.

Because a decade ago there was only Leiningen -- so all the books and tutorials (and videos) created in the early days of Clojure had to use it. At work, we started with lein (back in 2011 for our production code), then we switched completely to Boot in 2015, and then we switched completely to deps.edn in 2018. build.clj (tools.build) is a "recent" addition (less than two years since the very first 0.0.1 commit).

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.

How do we ever move the world forward if we are only allowed to have one thing?

Reply on news.ycombinator.com