This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-26
Channels
- # announcements (6)
- # babashka (29)
- # babashka-sci-dev (2)
- # beginners (129)
- # calva (9)
- # clara (16)
- # cljdoc (49)
- # clojure (125)
- # clojure-bay-area (3)
- # clojure-europe (55)
- # clojure-france (1)
- # clojuredesign-podcast (8)
- # clojurescript (85)
- # conjure (3)
- # core-logic (2)
- # cursive (1)
- # events (1)
- # honeysql (61)
- # jobs-discuss (23)
- # lsp (69)
- # malli (14)
- # nrepl (3)
- # off-topic (16)
- # portal (11)
- # re-frame (8)
- # releases (1)
- # ring (2)
- # shadow-cljs (12)
- # vim (42)
- # xtdb (18)
unfortunately a search for cannot be cast to class clojure.pprint.PrettyFlush
here or on GH does not help
@U0BBFDED7, happy to take a peek sometime today.
But first... I see many clojure .class
files in your jar. This is something you typically want to avoid for a library.
You probably want to use b/jar
instead of b/uber
https://github.com/ribelo/doxa/blob/9a9571f3e7c49bac186512028e99ed4f15eefcce/build/build.clj#L65-L67?
Oh @U0BBFDED7, one more thing: your cljdoc badge image seems a bit off: You have: https://cljdoc.org/badge/ribelo/doxa.svg But I think you maybe want: https://cljdoc.org/badge/com.github.ribelo/doxa
Hello 👋 just wanted to start off by saying cljdoc is a pretty awesome tool for the Clojure community! Thanks for all the hard work in both building and maintaining it 🙏 An issues I run into on occasion is resolving optional/runtime dependencies. So far I have been able to work around these issues, but was curious if there was any discussion around making it easier?
Hi @U1G869VNV! Thanks for dropping by!
Our current recommendation is to include optional deps as provided
in your pom.xml
.
The only option today for API analysis is dynamic analysis, your namespaces are loaded to discover your API. I am exploring adding support for static analysis via clj-kondo’s analysis data. Static analysis would not always cover the case where an API is generated at load-time, but not many libs do this, so it might be a good fallback/option if dynamic analysis fails.
It would be awesome if I could opt-in to the static analysis path for some apis/namespaces 💯
And am also looking at custom analysis. You provide the resulting API analysis edn that cljdoc normally generates. But… I don’t think this is what your use case specifically needs.
> It would be awesome if I could opt-in to the static analysis path for some apis/namespaces Oh… hadn’t thought of doing only for some namespaces… Hmm… I’d probably start with all static or all dynamic for an analysis run.
Recently I added some code for planck and had some issues, luckily planck does publish a jar to clojars so I was able to solve the issue.
Another option could be to exclude certain namespaces from being analyzed :thinking_face: Not sure what is easier
Just remembered that cljdoc does add at least one jar to the classpath that would fall into the provided category: javax.servlet/javax.servlet-api
.
> Another option could be to exclude certain namespaces from being analyzed :thinking_face: Not sure what is easier
If you have control over the source, you can add :no-doc
to a namespace.
A recent change to analysis will not attempt to explicitly load these namespaces.
But if they are loaded indirectly by other code in your lib, then… well… you’ll still have trouble.
Ohh, I think I might be using an older version of cljdoc locally for testing. I was hoping no-doc would do this 💯
Meh, it is typically lotsa fun! And always looking for feedback. It can get a little quiet in the ol’ cljdoc channel so feel free to drop by with ideas/problems/suggestions.
big oof
I'll probably just start that over
@lee iirc you use adoc? do you know of any clojure projects that use that as the readme? I'm working on client-side search again and I'm only parsing markdown at the moment and need it to work with adoc as well
oh, duh, I already have your status-line project open and it has that
disregard
sorry I dropped off the face of the earth btw
thanks for leading the charge on maintenance
so nice to be back!
I've been working on calva maintenance
but this weekend feels like a good time to knock out this client-side search. the value to the community would be incredible