@miikka good morning, nice to see the sourcehut thing in production 🙂 what do you think about stripping the leading ~
from the username in the SCM link text? Since it’s not something users choose I feel it’s non-essential and almost like a detail related to sourcehut that isn’t very relevant
That differentiation doesnt exist in the same consistent way across the different scm providers, which makes me feel it shouldn’t “leak” into cljdoc?
But idk, at the same time sourcehut repos aren’t going to be many for the foreseeable future so if sourcehut users consider the extra character useful I’m not gonna get in the way :)
Drew considers it significant. +cljdoc and ~cljdoc are completely separate.
Ah, I didn't know about this group syntax plan, but in that case I'd say let's keep the extra character in
For the unaware, like me before googling, Drew is Drew DeVault, the person who created sourcehut.
:man-shrugging: I thought about it and decided to keep it since sourcehut keeps it everywhere, but if you feel like removing it is better, that's fine by me
Hi there
Hi @timo!
Is it possible to configure cljdoc? I need to avoid cljs analysis on cljc files in my project
it throws errors and I need to postpone that
We don’t currently have a way to tell cljdoc to ignore cljs files.
Are the throws due to something cljdoc might be doing wrong?
I am not certain, but the error might be on my side and it errors still if I put ^:no-doc on top
We can hardcode an exception if it’s not something that can be fixed on the side of the lib
Does the file work with the Clojure script Compiler otherwise?
we are working on cljs-compat right now so it might be broken for cljs currently, but that's beyond me
it's datahike
https://cljdoc.org/d/io.replikativ/datahike/0.3.2/doc/readme
I would like to add only the api-ns
so I add no-doc everywhere and released a snapshot
https://cljdoc.org/d/timokramer/datahike/0.3.5-SNAPSHOT/doc/readme
no-doc just controls what parts of your api get exposed. Cljdoc will still load your entire project.
Yeah, and if a namespace required by the api ns can’t be loaded then that will also cause the api ns to fail to load
I wonder… have you thought about maybe keeping cljs work in a branch until it is ready for release?
Or does that not work?
Yeah I guess not. If you have cljc files. You are clj ready but not cljs ready… hmm…
yeah right
Personally, I think I’d just push through and get cljs side working before release. But that’s me. And maybe not what works for you?
as it comes from datascript mostly it was working once
that's actually not what I am working on
and I think it is a lot of work
so I just want to add the api-ns as docs
but I can find another way
thanks anyway
I think both arguments are valid. (How helpful of me! :simple_smile:). We are linking to sourcehut and that’s the syntax they use for a repo. We are linking from cljdoc and its not the syntax it has used for all other repos.
I admit it does look a bit weird
On coin toss things like this, I usually just go with what @martinklepsch prefers. :simple_smile:
We can totally hardcode it if it makes your life easier, there’s a file that explicitly supports this kind of hard coding so it wouldn’t have any extra maintenance overhead
ok perfect. that would be cool for now. it will take a few weeks until clojurescript is restored I guess.
https://cljdoc.org/d/io.replikativ/datahike/0.3.2/doc/readme
cool! thanks a lot. that version needs a few more no-docs though. but never mind
the hardcoding works based on group/artifact ID — which ones should cljs get disabled for?
io.replikativ/datahike
Is there an issue to track cljs compatibility?
Fwiw, in the future there will be a syntax for groups which differs
~ for users and something else like + for groups. So it's useful in a sense for distinguishing.