Clojurians Log v2
cljdoc
Has any more thought been given to situations where a library needs a dependency to be present for analysis but does not "depend" on that to be used? @sritchie09 just raised the issue of provided scope deps since you can't generate a pom.xml with tools.build that includes scope on deps. This has cropped up with several libraries in the past (including build-related stuff for cljs libs, I believe?).
I guess this is the issue I'm also bumping into then https://cljdoc.org/d/net.clojars.simtech/reagent-flow/v11.5.5
I haven't worked throught the docs yet though, so it might just be that I'm missing something
Maybe @hkjels, I see No such namespace: reactflow . Is that a dep you don't include in your artifact?
Huh, I don't see any sources on the github repo: https://github.com/dnv-opensource/reagent-flow, is that the right repo?
Anyhoo, please do start a new thread if you'd like to work out what is going on.
Yeah. The source is in the http://index.org file. OK. Thanks
Reading some docs now 🙂
Yeah, it does crop up as an issue from time to time.
I typically have an anemic pom.xml in my projects that use tools.build.
I suppose tools.build would wipe out an existing provided dep in a pom.xml when applying deps to an anemic pom.xml ?
Right, that's the issue: if you generate pom.xml using write-pom, it replaces <dependencies> with the default computed basis from deps.edn.
another solution would we static analysis which we talked about recently
I see, thanks @seancorfield. Hmm... The only other config we currently have is doc/cljdoc.edn . I suppose we could maybe add something in there.
Yeah @mkvlr, static analysis would fix many many (many) failing cljdoc builds.
I’ve added a provided dep and I’m trying to test it out with a snapshot build… I get https://cljdoc.org/builds/65960
an internal server error! probably unrelated
Sacre bleu!
Since you are here @sritchie09 you'd probably still need dynamic analysis if your API is generated from import-vars type techniques.
that’s not the case for this library, here I am shipping a mafs.sci namespace: https://github.com/mentat-collective/Mafs.cljs/blob/main/src/mafs/sci.cljs
that uses sci, but I don’t include SCI as a dependency
(since the user can ignore the namespace if they don’t want SCI)
@lee is that error an indication of a problem with handling provided dependencies? or unrelated?
@sritchie09, I'm not sure but maybe SNAPSHOT build support is currently broken. I can take a deeper look sometime soon. But am currently busy with a rewrite-clj issue.
No worries!
@sritchie09 for your snapshot release, in your https://repo.clojars.org/org/mentat/mafs.cljs/0.2.2-SNAPSHOT/mafs.cljs-0.2.2-20230209.171052-1.pom you have
<scm>
<url></url>
<connection>scm:git:</connection>
<developerConnection>scm:git:</developerConnection>
<tag>v0.2.2-SNAPSHOT</tag>
</scm> tag (of course) does not exist in your GitHub repo.
Cljdoc is wildly surprised by this (it really should not be so shocked), hence the current 500 error.
If I look at https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#snapshot-builds, we suggest the <tag> be set to the corresponding t commit sha for snapshot builds.
I'm noticing yours is not the only lib to slap a snapshot version in <tag> for snapshot builds.... perhaps cljdoc could be more forgiving here.
Or... at the very least provide a better error message.Sorry, it did exist when I ran the command, I deleted it afterward, after our conversation, I should have mentioned
Before I added that tag, the import in the first step failed
Oh, so we have 2 problems maybe!
I'm going to start a new thread to avoid spamming the (perhaps) uninterested.
@sritchie09 failing snapshot build 🧵
Continuing from https://clojurians.slack.com/archives/C8V0BQ0M6/p1675962025824019 this thread... but focused on Sam's failing snapshot build only
want me to push another one?
I pushed 0.2.1-SNAPSHOT after I forgot the tag, which is why I went to 0.2.2-SNAPSHOT…
so lame (of me)
Nah, not unless you want to... I don't think SNAPSHOT builds are typically git tagged...
If I fudge the pom scm tag to be a429c31ae2585fa89a62d16823893dd97b07c267 the docs build fine locally for me.
... for org.mentat/mafs.cljs version 0.2.2-SNAPSHOT.
oh, that’s a good idea — would you recommend always tagging via sha, vs an actual tag?
You could, but I think I'd only use the sha for snapshot builds. But you could. I think that might be the way lein works when it generates jars (I'd have to double check on that).
the snapshot for me was really just a test that the provided dep would work, this isn’t a blocker for me at all
(and thank you for checking that the build worked!!)
Yeah but your experiments are discovering lotsa stuff to help us improve cljdoc, so please keep on sharing!
Some folks put HEAD in <tag> for snapshot builds, I'm not a big fan of that because it means old snapshot builds will point to the latest git sources.
I was thinking... that maybe a default fallback might help for snapshot builds.
If the <tag> is not found fall back to HEAD.
But we'd probably want to share that the tag was not found somewhere.
Sometimes being helpful and magic is not really helpful at all.
I love my cljdoc since it’s the most stable place / best looking place to link to for var docs from my source code and clerk docs
Well glad you like it! We have a rag-tag team of maintainers, and it looks like I'm the current active one. But send a big ❤️ to @martinklepsch for creating cljdoc!
In any case I'm going to open an issue to improve error messaging here. We should not barf with a 500 error.
Here's the isssue: https://github.com/cljdoc/cljdoc/issues/749