This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-08-22
Channels
- # announcements (13)
- # babashka (22)
- # beginners (22)
- # biff (17)
- # calva (6)
- # clerk (20)
- # clj-kondo (25)
- # clj-together (5)
- # clj-yaml (20)
- # cljdoc (16)
- # cljs-dev (1)
- # clojure (42)
- # clojure-brasil (1)
- # clojure-europe (26)
- # clojure-nl (6)
- # clojure-norway (24)
- # clojure-turkiye (3)
- # clojure-uk (5)
- # clojurescript (37)
- # core-async (7)
- # core-logic (2)
- # datalevin (7)
- # datomic (43)
- # events (2)
- # fulcro (7)
- # gratitude (1)
- # hyperfiddle (7)
- # java (7)
- # jobs (3)
- # lsp (4)
- # off-topic (16)
- # pathom (18)
- # polylith (1)
- # portal (27)
- # reitit (4)
- # releases (3)
- # shadow-cljs (47)
- # tools-build (14)
- # tools-deps (16)
- # yamlscript (11)
https://stackoverflow.com/questions/76943471/clojure-deps-edn-not-resolving-dependency -- after a brief poke at this, it seems that something, somewhere in the chain of dependencies is requesting a version of babel__highlight that doesn't actually exist (7.x seems to be the highest version on Maven) and it looks like the waltid deps have a lot of <scope>
specifiers in their various POM files so I'm wondering if this is due to tools.deps
trying to follow a dependency that is marked with a <scope>
that it should perhaps be ignoring?
What would be an "easy" way to debug this, given that resolution ultimately fails?
tdeps should take compile and runtime scopes
I would probably debug it by loading tdeps in the repl and using a modified version of one of those commented out examples with a debugger
https://github.com/clojure/tools.deps/blob/be30a1ae275eabfd1eba571080e039451c122c69/src/main/clojure/clojure/tools/deps/extensions/pom.clj#L75 is where the scope filter is set
There's no "magic" debug or trace option that makes it write out resolutions as it goes?
Looks like the waltid ssikit pom is all compile/runtime so that's safe. But it depends on a ton of stuff so figuring our where in the full tree it breaks is going to be tedious 🙂
It's not my problem -- I just wanted to help the person on SO 🙂
It feels like some sort of "debugging mode" for deps resolution might be useful for situations like this -- instead of just "error! failed!" -- would you entertain a patch that added some sort of logging/trace mode that could produce output during resolution to help debug situations like this?
With your pointer, I modified trace+
to print entry
which helped... turns out that because tools.deps
picks the most recent version available on transitive deps, it managed to find org.webjars.npm/babel__code-frame
8.0.0-alpha1 which depends on a version range for babel__highlight that has not been released yet!
So I pinned that to 7.21.4 but I'm seeing quite a few
Download corrupted: Checksum validation failed, no checksums available
which doesn't seem to stop the CLI from continuing... I assume that can be "safely" ignored?Re debug, yes, but just has not seemed worth doing as I rarely need it (and I usually end up debugging such things anyway)
re checksums, I assume that's continuing because it's only a warning to be missing the checksums, but I haven't seen that before
(the printout from trace+
"helped" but still needed a fair bit of intuition about "how this all works" for me to narrow down the problem to a handful of dependencies that I then had to go check on Maven manually -- so I suspect you're right that this isn't widely useful)
Thank you for the valuable pointers tho'!
the info you need is often context dependent when debugging a problem and too much can be more harmful than helpful so... not an urgent need