Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure builds as an amalgamation of orthogonal parts

blog.fogus.me

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Clojure builds as an amalgamation of orthogonal parts

#21

Post by filoeleven »

fnordsensei wrote: post #19
synthc wrote: post #3

Earlier quoted context omitted.

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

I first used deps when doing a project with Datomic Cloud. I like deps, but I can’t quite articulate why.

After using it with Datomic Cloud, do you prefer it also for local projects? Is there something that happened with Datomic Cloud configuration that made it “click” for you elsewhere? Did you just have to use it there and that experience informed your preferences?

Data > functions > macros is a core concept of Clojure. Does that come into play here?

These are prompts from a curious outsider’s perspective.

Re: Clojure builds as an amalgamation of orthogonal parts

#22

Post by bokchoi »

synthc wrote: post #3
divs1210 wrote: post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

It's like we learned nothing from years of suffering with snowflake Ant builds.

Then again, gradle builds seems to be more popular than maven these days.

Re: Clojure builds as an amalgamation of orthogonal parts

#24

Post by john-shaffer »

filoeleven wrote: post #21
fnordsensei wrote: post #19

Earlier quoted context omitted.

I first used deps when doing a project with Datomic Cloud. I like deps, but I can’t quite articulate why.

After using it with Datomic Cloud, do you prefer it also for local projects? Is there something that happened with Datomic Cloud configuration that made it “click” for you elsewhere? Did you just have to use it there and that experience informed your preferences? Data > functions > macros is a core concept of Clojure. Does that come into play here? These are prompts from a curious outsider’s perspective.

I found an old thread that examines some of the early usage of deps. Data > macros does indeed seem to be a driving force: https://clojureverse.org/t/combining-tools-deps-with-leining...

tools.deps makes better choices when dependency specs conflict, so I would suggest trying https://github.com/RickMoynihan/lein-tools-deps if you otherwise want to use lein, and get the best of both worlds.

By better, I mean:

> Leiningen and Maven, when there is a conflict always pick the version that is closest to the root of the dependency tree; where as tools.deps always picks the newest.

Re: Clojure builds as an amalgamation of orthogonal parts

#25

Post by dustingetz »

AtticHacker wrote: post #12
bm3719 wrote: post #4

Earlier quoted context omitted.

Hard agree here. As a full time Clojure dev, my experience is that lein "just works". I've also used the Clojure Tools professionally, and have seen the dev team lose countless days of what would be otherwise productive time putzing with it, building infrastructure that lein has had out-of-the-box for years, and trying to make sense out of its inscrutable docs. Want a project with both Clojure and Java? Want tests th…

I agree. To me tools.build is not a replacement for Lein at all. Lein is more intuitive to most beginners. It's much easier to tell someone to run `lein new some-app` and `lein run` / `lein uberjar`, than to tell them to configure their deps.edn file so they can run some alias with the `-X:...` / `-M` arg to create and run a new project (and who knows which dependency to use / configure to build an uberjar). For expe…

> RICH HICKEY: I think that, collectively, we are infatuated with these two notions of easy. We are just so self-involved in these two aspects; it's hurting us tremendously. Right? All we care about is, can I get this instantly and start running it in five seconds? It could be this giant hairball that you got, but all you care is, can you get it.

Simple Made Easy is what attracted me to Clojure, and tools.build, tools.deps, tools.cli are aligned with this mission. Cognitect is doing exactly what they said they would do and have been doing all along.

Re-read the talk here: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

(PS, a note to Cognitect comms – maybe start here with your next blog post and see if people react differently!)

Re: Clojure builds as an amalgamation of orthogonal parts

#26

Post by beders »

dustingetz wrote: post #9
synthc wrote: post #3

Earlier quoted context omitted.

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

deps is extremely simple, which means very little time spent debugging, and it never breaks

deps can't produce stable builds as it insists dependencies are not ordered. Yet on the classpath they are. That order shouldn't matter, but it very well does.

lein AFAIK produces the same classpath every time.

deps: Maybe put the paths first and then let's gamble what a seq on a map produces...

Re: Clojure builds as an amalgamation of orthogonal parts

#27

Post by bananaoomarang »

I actually have found tools.deps to be pleasurable to use on new projects, though I haven't tried porting anything that previously used leiningen directly. It's simple, it's clear, I guess I find it pretty easy to reason about, but maybe that's because my experience with Lein was more 'copy and paste this huge config' and not really starting from scratch.

Re: Clojure builds as an amalgamation of orthogonal parts

#28

Post by fungiblecog »

What all the critics miss is that Lein is "Easy" but tools.deps, tools.build are "Simple". Rich wants all of clojure to be built from simple orthogonal parts that compose together. Ideally a multi-purpose tool like leiningen should be built on top of those simple parts. Other tools can re-use those parts in different ways. With Leiningen - its a great tool but it's a complex thing that you take on an all-or-nothing basis.

Re: Clojure builds as an amalgamation of orthogonal parts

#29

Post by cutler »

Clojure aficionados love to obesess over this stuff or maybe it's a leftover from their Java days. You come away from Rich Hickey's sermons on the Mount all fired-up with the value of simplicity and before you know it you're knee deep in Clojure's build tools maze - lein, boot, deps.edn, clij, shadow-cljs, tools.deps, tools.build. Clojure blazed the trail for simplicity but as far as build tools are concerned only Go managed to pull it off.

Re: Clojure builds as an amalgamation of orthogonal parts

#30

Post by filoeleven »

john-shaffer wrote: post #24
filoeleven wrote: post #21

Earlier quoted context omitted.

After using it with Datomic Cloud, do you prefer it also for local projects? Is there something that happened with Datomic Cloud configuration that made it “click” for you elsewhere? Did you just have to use it there and that experience informed your preferences? Data > functions > macros is a core concept of Clojure. Does that come into play here? These are prompts from a curious outsider’s perspective.

I found an old thread that examines some of the early usage of deps. Data > macros does indeed seem to be a driving force: https://clojureverse.org/t/combining-tools-deps-with-leining... tools.deps makes better choices when dependency specs conflict, so I would suggest trying https://github.com/RickMoynihan/lein-tools-deps if you otherwise want to use lein, and get the best of both worlds. By better, I mean: > Leinin…

Leinengen vs Maven dependency resolution is pretty distant to my concerns. I may be in the minority there, but I don’t think I am. I guess the thing I’m struggling to understand in the build tool differences is:

Leinengen’s (defproject) takes a series of keys and values. It is declarative. You can probably get into dependency hell if your config is complex enough, and I’m almost certain it’s doing more than I understand under the hood. (like why doesn’t it just take a map instead of being a macro?)

tools.deps OTOH appears to need both a bunch of top-level definitions in a namespace (instead of a map literal) AND a hand-rolled build.clj file with custom functions to do most of the things that leinengen considers to be boilerplate. This does imply that you have much more flexibility with tools.deps, but it also raises the bar for entry, and it doesn’t appear to be as data-centric.

If I want to do ANYTHING meaningful with Clojure, I need a project environment to start with. I am not confident about how to do this with clj, even after reading https://clojure.org/guides/deps_and_cli#_writing_a_program Maybe I just haven’t found the right guide, or maybe clj wants me to commit more to working REPL-first than my dev environment (VS Code + Calva) has good support for.

What I’m wondering now is, if the gains that tools.deps provide are worth the entry price, does it make sense to have something like “create-react-app” to generate a project directory with sane defaults that can be customized if/when needed, if your project doesn’t fit the 90% case? Does this already exist?

‘dustingetz linked the Simple Made Easy talk. I get the distinction between the two, and I don’t want to swallow the hairball. I’m already sold on the Clojure paradigm.

But I ALSO still want to “get this instantly and start running it in five seconds,” and I don’t understand why I’m not allowed that if I choose tools.deps. I don’t think the two goals are more than accidentally orthogonal.

Post reply on HN