undefined | Better HN

0 pointshlship1y ago0 comments

The cli/deps.edn tooling is different from Leiningen, and far, far less complicated IMO. I've written a good number of Leiningen plugins and it was always brutal to get anything to work properly, especially in combination with other plugins.

Leiningen attempts to be everything to everyone in terms of building, testing, and packaging Clojure code. It's Clojure's version of Maven.

cli/deps.edn effectively reduces things down to a) what should be on the classpath and b) what should get executed. Working inside an IDE? You just want it to download the dependencies and build a classpath. Running nREPL? Add that to the classpath, and set the starting namespace to start nREPL. Packaging an application? Run dependencies that do that work, based on the clojure.tools.build library.

I was there myself; I used Leiningen and didn't take the time to figure out deps.edn --- until I did, saw the light, and converted all of Walmart's projects to use deps.edn, which greatly sped up our build and improved our dev experience.

0 comments

KingMob1y ago

tools.deps is less complicated mostly because it just flat-out does much less. To mimic everything lein can do required adopting half a dozen other libs and writing your own build scripts.

It's better now, but people are pretty uncritical of the core team, and adopted tools.deps before its surrounding ecosystem was ready to fully replace lein.

The upshot was, everyone got to rebuild the wheel for a couple years. And I say this as someone who once lost a week debugging a subtle lein/maven classpath AOT bug.

j / k navigate · click thread line to collapse