Fork me on GitHub

WIP experiment to make a flexible scripting way of invoking tools.deps from the command line with babashka:


Util function:

(defn- merge-defaults [deps defaults]
  (let [overriden (select-keys deps (keys defaults))
        overriden-deps (keys overriden)
        defaults (select-keys defaults overriden-deps)]
    (merge deps defaults)))

(defn merge-default-deps [deps-map defaults]
  (let [paths (into [[:deps]]
                    (map (fn [alias]
                           [:aliases alias])
                         (keys (:aliases deps-map))))]
     (fn [acc path]
       (update-in acc path merge-defaults defaults))

(merge-default-deps '{:deps {medley/medley nil}
                      :aliases {:foo {medley/medley nil}}}
                    '{medley/medley {:mvn/version "1.3.0"}})

;;=> {:aliases {:foo {medley/medley {:mvn/version "1.3.0"}}}, :deps {medley/medley {:mvn/version "1.3.0"}}}
I assume you're doing kind of the same in your setup @seancorfield?

Alex Miller (Clojure team)15:12:22

why are you not using tools.deps to do this kind of thing?

Alex Miller (Clojure team)15:12:20

oh, you're actually updating aliases


@alexmiller This would be a way to generate a deps.edn value which can be used from scripting, assembled from as many deps.edn files as one wishes


as an alternative for the CLJ_CONFIG hack


But one could also use the above util function to emit a deps.edn file on disk and then have clojure use that.


@borkdude Yeah, something like that -- I'm also processing :extra-deps in aliases so that :override-deps from our template affects those too -- although I've realized that my processing doesn't correctly override transitive deps (which is why we went down the :override-deps path in the first place) so I need to make a few adjustments... and then I'm still going to be stuck as far as needing an alias for :override-deps for transitive deps which I've no way of passing in to some tooling that needs it. So it's all a bit of a mess at this point 😞


Fair to say that I'm very unhappy about it all at the moment.


The CLJ_CONFIG hack "works" for the :override-deps and alias usage we had -- but that backs us into a corner as far as tooling is concerned (since several tools don't include the user-level deps.edn file and several tools don't accept aliases to apply -- and some tools "fail" in both those areas).


And our new merge/generate deps.edn files from templates "works" for tooling but now has edge cases where transitive deps are not being overridden as we'd ideally like (and I'm actually surprised it hasn't bitten us yet since we've gotten this new "Frankenstein" build approach as far as our pre-production environment).


We're still using the CLJ_CONFIG approach, but maybe in time I'll just write a babashka runner script ( that gives us all the flexibility we need. We can just merge maps the way we like it and then pass it to tools.deps.


Yeah, I saw that. But we're not about to start adding yet more tooling across our stack -- we're trying to standardize and reduce the custom tooling, not add to it 😐


Understandable. Sure! Just as deps.clj, I don't expect anyone to use it because it's a custom non-official port, except for some it solves a real problem. Just helped another Windows user who had issues.


Let's hope these are temporary workarounds.


hey, when I update tools.deps/clj to, REBL's (rebl/ui) fails to load with java.lang.NoClassDefFoundError: Could not initialize class cognitect.rebl.impl.monaco__init. Reverting to seems to fix it.


@felipecortezfi I think I had to use -Sforce to recompute the dependency cache when I ran into that error ages ago.

Alex Miller (Clojure team)23:12:08

just updating to newer clj should trigger a recompute but agree that first step is -Sforce

Alex Miller (Clojure team)23:12:12

I'd also be curious which REBL version you're using, there have been a number of different variants of the REBL packaging that use different mechanisms to include transitive deps


let me try -Sforce. I'm using rebl-0.9.242


I think that's the current version (although I've stopped using it now so I may not have picked up the latest dev-local bundle).


out of curiosity, what are you using in its place, if anything?


I switched to Reveal. With the customizations in my dot-clojure repo, it provides a fairly similar experience. It provides more extensibility (partly because it is open source).


See for some information about the customizations I've built on top of Reveal.


thanks! I'll take a look


no luck with -Sforce 😕


there's an error before that monaco thing, though


Execution error (ClassNotFoundException) at (

Alex Miller (Clojure team)23:12:05

the problem here is not finding some deps, so question is why

Alex Miller (Clojure team)23:12:35

can you be more concrete about your deps.edn, and the command you're running?


as simple as it gets, I think:

➜  test-rebl clj -Sdeps '{:deps {com.cognitect/rebl {:mvn/version "0.9.242"}}}'
Clojure 1.10.1
user=> (require '[cognitect.rebl :as rebl])
user=> (rebl/ui)
Execution error (ClassNotFoundException) at (


Java version? JavaFX not being available?


I don't think that's the issue, since reverting tools.deps to an older version fixes the issue, but here goes:

➜  test-rebl java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-ga)
OpenJDK 64-Bit Server VM (build 25.222-bga, mixed mode)

Alex Miller (Clojure team)23:12:14

the problem here is that adoptopenjdk 8 doesn't have the javafx libs included

Alex Miller (Clojure team)23:12:47

so you'll need to either use the Oracle Java 8 or use a newer adoptopenjdk with the open javafx libs

Alex Miller (Clojure team)23:12:21

I don't actually think there is an easy to obtain set of javafx deps you can use with adoptopenjdk 8

Alex Miller (Clojure team)23:12:57

in other words, you've picked the only jdk available that's difficult to run javafx apps on :)