Hello all, I´m confuse about using boot or deps.edn. What is the advantage of using one beside other? I switched from lein to boot because seancorfield told me that with boot we can load deps "on-the-fly" and I was using a lib in lein to do this. I saw this https://twitter.com/seancorfield/status/1171275237805060096?s=20 and https://www.youtube.com/watch?v=CWjUccpFvrg&t=46s and in terms of dev workflow it seems other way to do things. What is the most benefit of using deps.edn?

@fabrao Boot provides a whole bunch of tools "out of the box" -- although it does not incorporate a test runner (last I checked you needed to add Adzerk's boot-test for that, nor is "boot new" technically built-in but it's an easy command-line dependency to use). As noted, the boot repl allows you to add new dependencies dynamically, and it has some file management tooling built in (such as building jar and uberjar files).

The CLI/`deps.edn` is simple and lightweight, with a range of easy to add tooling for running tests, building jar files, etc. There's an add-lib branch of tools.deps.alpha which you can use -- illustrated in my dot-clojure file -- to add new dependencies dynamically.

I would classify lein and boot as "easy" -- lein more so than boot -- whereas I would classify clj as "simple" (in the general Clojure sense of simple vs easy).

clj is about small, composable tools -- very much in Clojure's "idiomatic world view".

We switched from Leiningen to Boot back in 2015 because we needed more/easier programmability in our build chain. We developed a lot of custom tasks once we switched to Boot -- thousands of lines of dev/test/build code. We kind of lost sight of simplicity there somewhere 🙂

Our Boot setup already had dependencies in EDN files -- albeit a different format to deps.edn -- so when we were getting ready to switch, I wrote boot-tools-deps (since archived, as a bad idea), as migration step, but in the end we didn't use it.

As part of our switch to deps.edn, we took a long, hard view at all our Boot tasks and decided to streamline/simplify things. We're very happy with the decision to change over. We have just a simple shell script that wraps clojure so we can run multiple CLI commands from a single invocation.

(I will note that we were running into a couple of issues with Boot due to the size of our codebase and our heavy use of "pods", Boot's isolation feature, so we were "pushed" a bit -- it wasn't entirely a "jump")

Happy to chat more via DM any time about tooling, if you want @fabrao (it looks late for you right now -- you're about six hours ahead of me).

well, I don´t want to bother you at this time, but any time for me

The subject about deps.edn started in Clojure Brazil Telegram Group and your twit shows up and I research about it

It's early evening for me -- feel free 🙂 I'm online about 9am to 11pm Pacific most days 🙂

Does anyone recall the solution to "UnknownHostKey: http://github.com. RSA key fingerprint is ...."? We've started getting this on CircleCI. I'm fairly certain I've seen it before and can't remember the solution. The CI has a checkout SSH key.

I finally caved and added an AOT option for uberjars to seancorfield/depstar {:mvn/version "0.4.1"} -- https://github.com/seancorfield/depstar -- there are some caveats: you need to create the classes folder yourself (as a one-off) and you need to ensure that folder is on the classpath when you actually run depstar (the README suggests a :uberjar alias that takes care of that). It only AOTs the -m / --main namespace (but that transitively compiles all namespaces that are directly referenced from it -- it is not "compile all", like Leiningen).

I also updated seancorfield/clj-new {:mvn/version "0.8.2"} -- https://github.com/seancorfield/clj-new -- to take advantage of that for the app template; this also fixes the group/artifact in the pom.xml for generated template projects.

> clojure -A:new app myname/myapp
Generating a project called myapp based on the 'app' template.
> cd myapp/
> clojure -A:uberjar
Compiling myname.myapp ...
Building uber jar: myapp.jar
Processing pom.xml for {myname/myapp {:mvn/version "0.1.0-SNAPSHOT"}}
> java -jar myapp.jar 
Hello, World!
> 

(for lib and template types you can clojure -A:jar to build a JAR that should be deployable to http://clojars.org pretty much as-is, with a near-ready-to-roll pom.xml file)