8 ms·

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, b

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.

synthc 5y ago
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 5y ago
  deps is extremely simple, which means very little time spent debugging, and it never breaks
  - beders 5y ago
    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...
    - dustingetz 5y ago
      thanks, didn’t know that, will definitely be annoyed when i hit that someday
    - john-shaffer 5y ago
      That appears to have been true for only about a month: https://groups.google.com/g/clojure/c/WI3ddZRK4Bg/m/RtJVt3IZBwAJ https://groups.google.com/g/clojure/c/WI3ddZRK4Bg/m/RtJVt3IZ... https://github.com/clojure/tools.deps.alpha/commit/c22ad46c6cf913448ea33d40434e4e8dfb3ef2b3 https://github.com/clojure/tools.deps.alpha/commit/c22ad46c6...
  - divs1210 5y ago
    I have never stressed over or debugged Leiningen in my 6 years of Clojure experience. Not sure what you're on about.
- divs1210 5y ago
  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 5y ago
  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.
- fnordsensei 5y ago
  I first used deps when doing a project with Datomic Cloud. I like deps, but I can’t quite articulate why.
  - filoeleven 5y ago
    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.
    - john-shaffer 5y ago
      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-leiningen/658 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 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.
      - filoeleven 5y ago
        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 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.
- bokchoi 5y ago
  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.
  - pjmlp 5y ago
    That is what happens when a new generation has grown without Ant and then a giant behemoth with endless cash for top hardware gets a deal to push Gradle as the official build tool for their mobile OS.
    - vore 5y ago
      I would think that Gradle is a lot more pleasant to use than Ant...
      - pjmlp 5y ago
        Not for those that don't suffer from XML allergy, so given that, the outcome is almost the same, with the caveat that Gradles uses a ton of more resources than Ant, as it needs its background daemon sucking up 2GB to pretend being fast.
bm3719 5y ago
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 5y ago
  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.
  - dustingetz 5y ago
    > 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/Hickey_Rich/SimpleMadeEasy.md 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!)
dustingetz 5y ago
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.project.clj https://github.com/technomancy/leiningen/blob/master/sample.... . If leiningen works for you, great, keep using it!
- bm3719 5y ago
  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.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 5y ago
    To be clear, you are pointing to this as an equally contrived example as what ‘dustingetz linked to, correct?
    - bm3719 5y ago
      Correct.
  - seancorfield 5y ago
    That isn't a project deps.edn file though -- it's a compendium of tools that are available for the CLI/deps.edn and I put it together as a working example so folks coming to the CLI/deps.edn stuff could see the broad range of tools available and could copy'n'paste any useful bits they want. The README explains that and even links to a better-documented and more carefully curated set of aliases that folks might want to use instead (the Practicalli repo). In reality, I use very, very of those aliases from that dot-clojure file, because the projects I work with already have the ones I need for working on those projects. That can be as simple as a :test alias or it can be up to a dozen aliases used in variations combinations for a variety of tasks. You can certainly use the CLI and deps.edn for ClojureScript, by the way -- check out Figwheel Main which uses deps.edn and provides a nice workflow.
mapgrep 5y ago
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 5y ago
  I have worked on pretty large Clojure projects, and found Leiningen to be perfectly adequate.
  - cutler 5y ago
    Although I prefer Lein at this point one of its disadvantages not mentioned here is that it requires its own JVM process which means you're running 2 JVMs during development.
    - jgalt212 5y ago
      but probably good and bad. pretty tough for one namespace to bleed into another due to a bug or incorrect config. bad, obv, because all the RAM the JVM needs.

synthc 5y ago

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 5y ago
deps is extremely simple, which means very little time spent debugging, and it never breaks
- beders 5y ago
  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...
  - dustingetz 5y ago
    thanks, didn’t know that, will definitely be annoyed when i hit that someday
  - john-shaffer 5y ago
    That appears to have been true for only about a month: https://groups.google.com/g/clojure/c/WI3ddZRK4Bg/m/RtJVt3IZBwAJ https://groups.google.com/g/clojure/c/WI3ddZRK4Bg/m/RtJVt3IZ... https://github.com/clojure/tools.deps.alpha/commit/c22ad46c6cf913448ea33d40434e4e8dfb3ef2b3 https://github.com/clojure/tools.deps.alpha/commit/c22ad46c6...
- divs1210 5y ago
  I have never stressed over or debugged Leiningen in my 6 years of Clojure experience. Not sure what you're on about.
divs1210 5y ago
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 5y ago
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.
fnordsensei 5y ago
I first used deps when doing a project with Datomic Cloud. I like deps, but I can’t quite articulate why.
- filoeleven 5y ago
  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.
  - john-shaffer 5y ago
    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-leiningen/658 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 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.
    - filoeleven 5y ago
      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 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.
bokchoi 5y ago
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.
- pjmlp 5y ago
  That is what happens when a new generation has grown without Ant and then a giant behemoth with endless cash for top hardware gets a deal to push Gradle as the official build tool for their mobile OS.
  - vore 5y ago
    I would think that Gradle is a lot more pleasant to use than Ant...
    - pjmlp 5y ago
      Not for those that don't suffer from XML allergy, so given that, the outcome is almost the same, with the caveat that Gradles uses a ton of more resources than Ant, as it needs its background daemon sucking up 2GB to pretend being fast.

bm3719 5y ago

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 5y ago
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.
- dustingetz 5y ago
  > 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/Hickey_Rich/SimpleMadeEasy.md 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!)

dustingetz 5y ago

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.project.clj https://github.com/technomancy/leiningen/blob/master/sample.... . If leiningen works for you, great, keep using it!

bm3719 5y ago
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.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 5y ago
  To be clear, you are pointing to this as an equally contrived example as what ‘dustingetz linked to, correct?
  - bm3719 5y ago
    Correct.
- seancorfield 5y ago
  That isn't a project deps.edn file though -- it's a compendium of tools that are available for the CLI/deps.edn and I put it together as a working example so folks coming to the CLI/deps.edn stuff could see the broad range of tools available and could copy'n'paste any useful bits they want. The README explains that and even links to a better-documented and more carefully curated set of aliases that folks might want to use instead (the Practicalli repo). In reality, I use very, very of those aliases from that dot-clojure file, because the projects I work with already have the ones I need for working on those projects. That can be as simple as a :test alias or it can be up to a dozen aliases used in variations combinations for a variety of tasks. You can certainly use the CLI and deps.edn for ClojureScript, by the way -- check out Figwheel Main which uses deps.edn and provides a nice workflow.

mapgrep 5y ago

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 5y ago
I have worked on pretty large Clojure projects, and found Leiningen to be perfectly adequate.
- cutler 5y ago
  Although I prefer Lein at this point one of its disadvantages not mentioned here is that it requires its own JVM process which means you're running 2 JVMs during development.
  - jgalt212 5y ago
    but probably good and bad. pretty tough for one namespace to bleed into another due to a bug or incorrect config. bad, obv, because all the RAM the JVM needs.