Any serious work will need a build tool of some sort. If you use lein, it comes with its own dependency management and config. Same for boot (as far as I know). So in practice, if I use tools.deps, I've now doubled the number of tools I depend on. I need lein and tools.deps.
At World Singles Networks, we’ve just completed our shift from a complex Boot-based pipeline to just clj/deps.edn and a small shell script to make the invocation simpler. We originally started with Leiningen (back in 2011). We switched to Boot at the end of 2015 (you can read why, and details about our journey, here: http://corfield.org/blog/categories/boot/ ). We still have two small Boot tasks, related to legacy projects, that I will likely convert this week. I’ll write a lengthy blog post (or two or more) about why we made this switch and what pros and cons we encountered, but I’d sum it up as “simplicity”. We are now dependent solely on a small, focused tool that is “standard” with Clojure. For deployment, we still build uberjars (using my fork of depstar that fixes a couple of bugs, and adds “thin” JAR support). We start those JARs with java -cp path/to/the.jar clojure.main -m our.namespace which is pretty much what we were doing with Boot (we used java -jar path/to/the.jar -m our.namespace but switched to the slightly longer form just before we migrated to clj/deps.edn). We use Cognitect’s test-runner, we use Olical’s depot (to track outdated dependencies). I’ve published JARs to Clojars using just clj -Spom, clj -A:jar (invoking depstar), and mvn deploy:deploy-file (the only thing I actually use Maven for!). As I’ve worked on various Contrib libraries (that already have pom.xml and use Maven on the CI system), I’ve removed the “convenience” project.clj files that were originally added to make working with those projects easier (e.g., to start an nREPL server, to run tests with multiple versions of Clojure etc) and replaced them with deps.edn files – and by using aliases for different Clojure versions, I can do multi version testing like this: for v in 1.6 1.7 1.8 1.9 master; do clojure -A:test:$v; done I’ve published my .clojure/deps.edn file on GitHub https://github.com/seancorfield/dot-clojure as an example of tooling integration with a clj-based workflow: starting nREPL servers, running Eastwood, benchmarking, testing, building JAR and uberjar files, even creating new clj-based projects. If you’re happy with Leiningen or Boot, there’s no reason for you to switch. You can still adopt the new deps.edn format and use https://github.com/RickMoynihan/lein-tools-deps or https://github.com/seancorfield/boot-tools-deps to integrate it, if you wish. One important caveat to consider right now is that there is no support for Windows for clj/deps.edn projects (I develop on both macOS and Windows 10 – I just use WSL with Ubuntu on the latter – and at work everything is deployed to Linux). Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ________________________________ From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Didier <didi...@gmail.com> Sent: Saturday, November 3, 2018 8:46:45 PM To: Clojure Subject: What's the end goal for tools.deps? I read the rationale, and I understand that we needed a way to bundle depencies for clj and clojure cli. But in practice, I'm seeing a lot of people move to it, away from boot or lein, and I fail to see what the end goal really is? Any serious work will need a build tool of some sort. If you use lein, it comes with its own dependency management and config. Same for boot (as far as I know). So in practice, if I use tools.deps, I've now doubled the number of tools I depend on. I need lein and tools.deps. For me, it seems the benefit would be around unified dependency config format and maybe reuse of the resolver logic. Like say Lein and Boot and all tools needing to specify dependencies adopted the format of tools.deps. This would be nice, especially for source based dependencies, and dealing with transitive dependencies in such case. So, is there any hope/work to adopt the format in Lein and Boot? Or what is the end goal otherwise? Regards -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
