[HN Gopher] Clojure builds as an amalgamation of orthogonal parts
___________________________________________________________________
Clojure builds as an amalgamation of orthogonal parts
Author : fogus
Score : 44 points
Date : 2021-07-20 15:12 UTC (7 hours ago)
(HTM) web link (blog.fogus.me)
(TXT) w3m dump (blog.fogus.me)
| thom wrote:
| Given the general tone of comments here, I thought it worth
| pointing out the advantages of using deps.edn instead of a
| Leiningen project:
|
| - REPLs start up very slightly quicker
| divs1210 wrote:
| 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 guess Open Source Is
| Not About Me.
| dustingetz wrote:
| Leiningen is over 10 years old and has tons of pain points. For
| example, I bet you're not using ClojureScript, which is a mess
| of plugin debugging in leiningen. The goal of tools.build is to
| let you code your builds as simple functions that run at the
| REPL, which is _awesome_. No more finding misplaced keys in
| soup like
| https://github.com/technomancy/leiningen/blob/master/sample....
| . If leiningen works for you, great, keep using it!
| bm3719 wrote:
| What pain points are those? Last I checked, doing cljs on
| Clojure Tools wasn't even possible. If that's still the case,
| then that's not a valid comparison (complex vs impossible).
|
| Also, that's the master version of project.clj, which is a
| superset of all possible features lein supports. Nobody's
| project.clj file looks like that, though I suspect you know
| this. Should we compare that complexity to a monster
| build.clj and this master deps.edn:
|
| https://github.com/seancorfield/dot-
| clojure/blob/master/deps...
|
| Lein is also a singular tool vs. a murky interaction between
| a suite of tools (tools.deps with deps.edn, Clojure CLI, and
| tools.build).
| filoeleven wrote:
| To be clear, you are pointing to this as an equally
| contrived example as what 'dustingetz linked to, correct?
| bm3719 wrote:
| Correct.
| filoeleven wrote:
| That file says at the top: ;; This is an
| annotated reference of the options that may be set in a
| ;; project.clj file. It is fairly contrived in order to cover
| lots of ;; different options; it shouldn't be
| considered a representative ;; configuration.
|
| The comment from 'bm3719 makes tools.build sound like a less
| useful solution when compared to the practicality of
| leinengen, and your reply only has ClojureScript in its favor
| if I trust that the linked sample project.clj is indeed not
| representative (which matches my limited experience with my
| own "useful toy" projects and the other projects I have
| browsed). "awkward stuff like inlining strings of eval-ed
| clojure code in your build file" sounds really bad, but that
| could be equally contrived for all I know.
|
| I also don't understand the value of running builds from the
| REPL. What kind of developer process makes that a useful
| thing to have? What am I missing?
|
| These are genuine questions, not advocacy for one thing or
| the other. I want to work professionally with Clojure(Script)
| enough that it is a prerequisite for me to consider changing
| jobs. I've only used lein thus far, so I don't have enough
| experience with either tool to share a meaningful opinion
| here. I am extremely curious about the state of things
| though.
| mapgrep wrote:
| Ya, this accords with my thoughts when I first saw this bubble
| up, I don't understand the benefit over just using lein, which
| is very easy and straightforward (for my use case). I thought
| maybe this new approach is needed by people with complicated
| builds? My own builds have been quite simple so far, but I'm
| new to Clojure.
| divs1210 wrote:
| I have worked on pretty large Clojure projects, and found
| Leiningen to be perfectly adequate.
| bm3719 wrote:
| 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 that
| magically integrate with CIDER's test functions? Complex build
| profiles for different target environments? Lein makes this
| stuff as painless as possible, whereas these things are
| possible with Clojure Tools, but have fun wasting time messing
| with it and doing awkward stuff like inlining strings of eval-
| ed clojure code in your build file. With Leiningen these are
| solved problems.
|
| I also find the core team's behavior perplexing. I'd argue the
| messy tooling they've been producing has probably been net
| negative value add to their community. Working downstream from
| this stuff has degraded the dev experience. Thankfully, it can
| be safely ignored.
| AtticHacker wrote:
| 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 experienced Clojure developers this might seem trivial,
| but new people (in my experience) are very impatient and want
| to get started ASAP. Honestly, who can blame them? Why does
| it have to be so difficult in this day and age?
|
| Another thing I hear Clojure developers say is that beginners
| can start with Lein, but once you get more experienced with
| Clojure you can switch to tools.build. Why does a build tool
| need to be so unusable that you can only use it when you
| become more familiar with the language? You don't see that
| with Ruby's Bundler, or Elixir's Mix. They just work, just
| like Lein does.
| divs1210 wrote:
| > I'd argue the messy tooling they've been producing has
| probably been net negative value add to their community.
|
| I feel the same way. It has definitely hurt the ecosystem.
|
| Every Clojure IDE, for example, has to support a new
| deps/build system that is still a WIP and doesn't come with
| batteries.
| synthc wrote:
| 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 made to do all these things, and more, but you need
| to configure it. Which test runner should I use for tests?
| Which library should I use to build an uberjar? Since it's all
| configurable, I risk that every deps project gets it's own
| special snowflake build setup, and I need to spend time
| avoiding this.
|
| Until deps gets a standard way for building and testing, i'm
| sticking to leiningen.
| dustingetz wrote:
| deps is extremely simple, which means very little time spent
| debugging, and it never breaks
| divs1210 wrote:
| I have never stressed over or debugged Leiningen in my 6
| years of Clojure experience.
|
| Not sure what you're on about.
| divs1210 wrote:
| Same. I don't want to spend time learning build tools and
| configuring builds - I want to Get Shit Done.
|
| Lieningen gets out of my way and lets me do the things that
| really matter, and I'm not switching till I see some clear
| advantages of the new tooling.
| tut-urut-utut wrote:
| Exactly. Lein is like maven, declarative and just works in a
| standard way for 95% of use cases. Deps is like ant, can do
| anything, super flexible, but you need to start from scratch
| actually programming your build for every project.
| bokchoi wrote:
| 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.
| fnordsensei wrote:
| I first used deps when doing a project with Datomic Cloud.
|
| I like deps, but I can't quite articulate why.
| filoeleven wrote:
| 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.
| fmakunbound wrote:
| I don't understand why deps was needed and I'm surprised its
| authors didn't foresee the confusion it would create. I'm also
| confused as hell what I should be using now, and the idea of
| researching deps seems exhausting. I'll just stick to cutting and
| pasting onto my leiningen config I think.
| raspasov wrote:
| Very well written post. Simplicity is a good thing!
___________________________________________________________________
(page generated 2021-07-20 23:01 UTC)