Clojurians Log v2
cljdoc
Maybe you'll advise a better way to do the following.
I'd like to release on Clojars a library that depends on tools.build. Since it is a git dependency, it won't appear in the POM file or anywhere in the jar and cljdoc analysis will fail ; tools.build will be missing.
My solution is to wrap the tools.build functions I need in delays with a requiring-resolves and deref at runtime. That way, analysis should pass and users can add tools.buildto their project themselves.
However this is certainly cumbersome. Any other alternatives? 🙏
@seancorfield Well the lib is part of a monorepo in construction and as such can't be imported as a git dep. This is because prepping a lib is fully static and cannot take any arguments. Until this is true, I don't think it will be possible consuming only part of a monorepo.
@adam678 The poly tool is part of a monorepo but can be used as a git dep -- see :deps/root for how to point a git dep into a monorepo.
From a practical p.o.v. you really can't release libraries to Clojars (or Maven) if they rely on git deps -- you have to release them as git deps. There's a lot of tooling that isn't going to work properly, I suspect, and I have to ask: if your users need to add tools.build as a local git dep anyway to use your library, why not release your library as a git dep (and then it can depend on tools.build and users won't also need to add that themselves)?
I see no value in releasing such libs to Clojars -- only downsides.
Oh thanks @seancorfield for answering, and sorry @adam678 for not noticing your followup!
Also note: cljdoc only currently supports building docs from clojars released libs. We don’t yet have support building from a git hosted projects.
Hiya @adam678! What some folks do is include those deps in their poms but mark them with a scope of provided. Here’s https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#getting-dependencies-right in our docs.
Thanks @lee! But how would that work with a git dependency? 🤔
@seancorfield I asked about that on #tools-deps to get a general answer but maybe you have a more practical experience. What happens when the same polylith repo is consumed twice as a gitlib? By pointing to different :deps/root?
They are treated as separate deps (since they have separate lib names).
Ah, I see Alex mentioned the transitive deps issue which, yeah, use true for any transitive deps that can conflict and can't be compared.
So my hypothesis was there shouldn't be any problem as long as libs from the same repo are required with the same SHA. At least in a polylith-style repo where libs refer to other local libs via :local/root.
Do you concur?
(I’m not sure but I think you two aren’t talking about cljdoc anymore, that’s totally fine, but if you have cljdoc questions, lemme know, and I’ll try to answer them)
Yeah, this really wasn't a cljdoc Q 🙂