This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-04
Channels
- # announcements (7)
- # aws (5)
- # babashka (72)
- # beginners (43)
- # calva (12)
- # cider (9)
- # clara (3)
- # clj-kondo (12)
- # cljdoc (32)
- # cljs-dev (10)
- # cljsrn (1)
- # clojure (78)
- # clojure-dev (50)
- # clojure-europe (17)
- # clojure-gamedev (8)
- # clojure-nl (1)
- # clojure-spec (30)
- # clojure-uk (3)
- # clojurescript (52)
- # core-async (1)
- # cursive (5)
- # datomic (8)
- # emacs (58)
- # events (2)
- # fulcro (5)
- # graalvm (7)
- # holy-lambda (37)
- # honeysql (9)
- # jobs (5)
- # leiningen (3)
- # lsp (7)
- # lumo (2)
- # malli (3)
- # meander (13)
- # membrane-term (64)
- # missionary (19)
- # music (3)
- # nextjournal (8)
- # off-topic (29)
- # pathom (16)
- # polylith (14)
- # portal (16)
- # re-frame (2)
- # reagent (5)
- # sci (14)
- # shadow-cljs (20)
- # spacemacs (6)
- # sql (1)
- # tools-deps (58)
- # vim (14)
looks interesting: https://twitter.com/wcrichton/status/1456112165744615426
you can detect where these functions are being used with the clj-kondo analysis quite easily
Hey, so I have a project, farolero, that I have getting documented with cljdoc. Things have mostly worked fine until the most recent release.
Here's the build job, but I'll summarize the issue next: https://app.circleci.com/pipelines/github/cljdoc/builder/24960/workflows/37a583b4-23b8-4166-8f53-0ae3527c47e6/jobs/41335
The problem is that I (intentionally) require a namespace from a library I don't depend on.
And I have it in a try/catch to detect if a given library is available, and automatically load some extensions if it is.
Is there something I can do to make it so that it doesn't choke on this namespace?
If you catch the exception that should work @suskeyhose
If you want to make additional dependencies available to the analysis job you can specify them with the maven scope "provided"
One thing I'm going to try is to put no-doc on the namespace form that depends on the library
And if this doesn't work, I might move the require form for the namespace that isn't in the dependencies out of the ns form
That won’t help here since no-doc is filtered for after analysis and it’s the analysis step that fails
aaah, okay
I could try the provided. Is that just something I have to add in my pom?
Might be a nice idea to introduce some static analysis to the analysis process to filter out no-doc before the full dynamic analysis
Can you link to the code that throws the exception?
I too am having the similar issue: https://app.circleci.com/pipelines/github/cljdoc/builder/24887/workflows/f2dc453e-add5-4826-9b16-31aa5da84605/jobs/41262 The require is in an ns which should not be read if the runtime is the jvm. my lib: https://github.com/lispyclouds/contajners is supposed to be able to be run on both the jvm and babashka. what would be a solution here? I'm using a reader conditional for this: https://github.com/lispyclouds/contajners/blob/main/src/contajners/core.cljc#L3-L4
https://github.com/IGJoshua/farolero/blob/master/src/cljc/farolero/extensions/flow.cljc This ns requires the library https://github.com/IGJoshua/farolero/blob/master/src/cljc/farolero/core.cljc#L19-L31 This is the code that requires that ns and catches the exception
@martinklepsch If you're interested in static analysis, clj-kondo is now able to return arbitrary metadata of vars and namespaces since the last release.
Basically I have to do this because I use the exception mechanism for unwinding, and flow unfortunately catches throwable and not exception, which will catch everything that extends java.lang.Error, which is explicitly designed to not be caught, which is why farolero uses it. I have to then load an extension for flow and any other libraries that I discover do something similar at runtime to extend their mechanisms to allow farolero to act transparently.
at the same time though I can't actually bring in those libraries as dependencies because I don't want to bloat someone's program if they're not using those error handling mechanisms
Ok so the issue here is that cljdoc will try to load your extension namespace, probably the best workaround is to add the required dependencies with scope provided
I can try that next
I think the best solution for everyone here is to fail analysis at the namespace level but so far that hasn’t been implemented and the analysis will fail entirely if one of the namespaces in the artifact can’t be analysed
Would another option would be to allow cljdoc.edn
to specify which namespaces to exclude in API analysis?
I think it is helpful for cljdoc to fail when things seem amiss rather than automatically compensating in (maybe mysterious) ways.
Yes that might also work
And I think is probably a bit easier to achieve from where we are now
If only I wasn’t so distracted by #membrane-term right now! And https://github.com/borkdude/api-diff ! And… ?