explore using tools.deps instead of pomegranate/aether

[benedekfazekas]

as means of resolving dependencies

[lread]

Cljdoc uses clojure/tools.deps.alpha to resolve deps. It seems to work pretty well.

No sure if MrAnderson cares, but one thing it does not handle yet is bom dependencies.

[benedekfazekas]

hm.. that is an interesting one. Using tools.deps.alpha feels the right way to go, and I don't think any MrAnderson's known clients use BOM deps. It also seems that tools.deps will eventually add BOM support. We can also add our own workaround if this becomes an issue...

[lread]

Yeah, listing the individual artifacts instead of the bom is the work-around we recommend for cljdoc API analysis.

Seems like the parallel loading issue has been fixed so that's good (actually not sure if that one would have even affected us).

Antq also uses clojure/tools.deps.apha for resolving deps so we can look to its code for inspiration too.

If I remember correctly, the min Clojure version for clojure/tools.deps.alpha is 1.10. If we look at the current build matrix, that seems to be the case:

Is a min version of Clojure 1.10 a problem at all for MrAnderson?

[benedekfazekas]

hm... looking at cider-nrepl CI file, it seems so. however obviously munging the source with mranderson is just a step in the build process which could be tied down to use a specific clojure version I guess. that needs some adjustments downstream tho

[lread]

Ya, that's what I figured, thanks.

If MrAnderson were integrated into some tooling that needed to support Clojure < 1.10 then we'd have an issue. But it is basically run as a stand-alone tool if I understand correctly.

[lread]

I remember @vemv fighting the good fight to have rewrite-clj support Clojure >= v1.8 (he convinced me!), but that was because rewrite-clj is used in other tooling.

[lread]

So @benedekfazekas, as I swing some of my attention back to MrAnderson: what problem would we be solving by moving to tools.deps?

I am now a maintainer on pomegranate, so I have a deeper (but by no means full) understanding of its inner workings.

Both pomegranate and tools.deps use aether under the hood.

Tools.deps does support more than just maven though, it can reference, git, local and pom deps. So that's a plus.

I think that tools.deps resolves deps differently than pomegranate though. I.e. which dep is chosen for dep a with versions a, b and c. We'd probably (?) want to take a look how resolution differs and if that would impact/confuse lein users.

Maybe we'd want to resolve with pomegranate for lein projects and tools deps for deps.edn projects?

[benedekfazekas]

I don't think there is a specific problem to be solved here. this was only to explore which you already partly did in your comment ;) supporting other means of dependencies not just maven sounds cool but also not tirvial. I would say this is low prio at this point, specially if pomegranate is maintained (by you).

[lread]

Thanks for the reply @benedekfazekas, much appreciated. We'll have to explore how MrAnderson would support deps.edn projects without tools.deps.

Maybe just have MrAnderson parse deps.edn to learn about the specified default deps and then resolve those with pomegranate.

If only using pomegranate, MrAnderson would have to fail if any of those deps are not :mvn/version deps.

Or... maybe we just use tools.deps for deps.edn projects. Probably worth exploring both approaches to see which one plays out more cleanly. Still would likely only support :mvn/version deps initially as some decisions would have to be made how to support other types of deps.