Clojurians Log v2

The intention is not to run two separate tools - but to use the deps and paths from alias (ignoring the -m). Similar to what was possible to achieve using -c and -r opts

WIP experiment to make a flexible scripting way of invoking tools.deps from the command line with babashka: https://twitter.com/borkdude/status/1336621562682880000

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))))]
    (reduce
     (fn [acc path]
       (update-in acc path merge-defaults defaults))
     deps-map
     paths)))

(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"}}}

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

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 (https://clojurians.slack.com/archives/C6QH853H8/p1607510436354200) 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 1.10.1.739, REBL's (rebl/ui) fails to load with java.lang.NoClassDefFoundError: Could not initialize class cognitect.rebl.impl.monaco__init. Reverting to 1.10.1.507 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.

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

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).

no luck with -Sforce 😕

there's an error before that monaco thing, though

Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:382).
netscape.javascript.JSObject

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

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

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

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 https://github.com/seancorfield/dot-clojure#the-dev-alias for some information about the customizations I've built on top of Reveal.

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])
nil
user=> (rebl/ui)
Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:382).
netscape.javascript.JSObject
user=>

thanks! I'll take a look

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)

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

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

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

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