Fork me on GitHub
#tools-deps
<
2023-08-22
>
seancorfield00:08:15

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?

Alex Miller (Clojure team)00:08:13

tdeps should take compile and runtime scopes

Alex Miller (Clojure team)00:08:22

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

seancorfield00:08:17

There's no "magic" debug or trace option that makes it write out resolutions as it goes?

seancorfield00:08:18

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 🙂

seancorfield00:08:32

It's not my problem -- I just wanted to help the person on SO 🙂

seancorfield00:08:17

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?

seancorfield01:08:51

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!

seancorfield01:08:34

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?

Alex Miller (Clojure team)01:08:42

Re debug, yes, but just has not seemed worth doing as I rarely need it (and I usually end up debugging such things anyway)

Alex Miller (Clojure team)01:08:20

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

seancorfield01:08:02

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

seancorfield01:08:29

Thank you for the valuable pointers tho'!

Alex Miller (Clojure team)01:08:35

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