To use add-lib3 branch as Sean Corfield said he is using in his recent REPL-Driven Development talk to London Clojurians group, is it necessary to run any git clone, checkout add-lib3 branch, build, etc. steps to use that? Has Sean or someone written up instructions on any installation steps required to use that branch?

@andy.fingerhut It's in my dot-clojure repo (as I said in that talk 🙂 )

https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L192-L215

The only caveat with a Socket REPL is you need to ensure a DCL between starting it up. Hence the weird -e stuff in my dot-clojure file -- and also in the dev.clj file in that repo.

I believe that'll be fixed in Clojure 1.11 based on what Alex has said.

You did, and thanks for that talk and all the stuff you release! Never having used it, I was assuming that there might be some mvn install step somewhere, but it looks like no? It is overriding the default version of tools.deps.alpha with a particular git sha, likely the latest commit on the add-lib3 branch, and that is enough. Cool. Will give it a go.

Yeah, just a git dep, since it's on a branch.

I sometimes guess that things will be extra work to use than they actually are, and am pleasantly surprised otherwise.

I've gotten very used to my setup now -- works on both macOS and Windows (WSL2/VcXsrv) -- Socket REPL, Reveal, add-libs, VS Code. It's a really nice Clojure dev env.

I often have multiple Socket/Reveal setups active -- SOCKET_REPL_PORT=... clojure -M:rebel:reveal:test:add-libs:dev/repl -- and just connect to whichever one I'm currently working on.

one caveat is that using it as a git dep means you don't get the compiled Java class that provides access to s3 maven repos so that one feature will not work with add-lib3 branch

Good point! Thanks for the reminder, yes! I should probably add that to the comment in my deps.edn file.

(added)

@seancorfield Didn't you write a blog post about how you work with deps on a monorepo?

I can't seem to find it, if I didn't just dream it

@mpenet since Sean is asleep probably: if I recall correctly he first used the CLJ_CONFIG hack to merge deps.edn from a common dir, he then stepped away from this and now use deps.edn generation using some scripting. https://clojurians.slack.com/archives/C6QH853H8/p1611959382106000 I can't recall that he ever blogged about this.

seems like a sound solution

thanks for the pointer

that could be a deps plugin btw 🙂

@mpenet FWIW babashka contains a function to merge deps files:

$ bb -e "(babashka.deps/merge-deps ['{:aliases {foo {}}} '{:aliases {bar {}}}])"
{:aliases {bar {}, foo {}}}

I'd just need the part that factors out the deps coordinates/versions for all "sub-modules" really

so it's an easy little clj "script" that can be used via an alias potentially

@mpenet There is also this undocumented function:

$ bb -e "(babashka.deps/merge-defaults '{:deps {foo/bar nil}} '{foo/bar {:mvn/version \"1.10.2\"}})"
{:deps {foo/bar {:mvn/version "1.10.2"}}}

I wasn't sure about the API and name yet, this is why it's undocumented

The code for this is public though, if you want to steal it

I'd prefer to only rely on clj, but I ll have a look, thx

yes, this is just messing with maps, nothing bb specific

@mpenet Yeah, I should write all that up as a blog post some time... I'm not very happy with either "solution": CLJ_CONFIG was convenient and worked well except devs could not have their own tooling; generating deps.edn from a pair of template EDN files works but has edge cases around transitive deps changes (t.d.a already has issues with :local/root deps in that respect -- and trying to keep the generated deps.edn files up to date automatically makes that a bit worse).