Fork me on GitHub

maybe clj-kondo & friends have all the things ready to us to have this in clojure…


you can detect where these functions are being used with the clj-kondo analysis quite easily


… STILL waiting for a new library/example to pop up just for this 🙂

Joshua Suskalo17:11:49

Hey, so I have a project, farolero, that I have getting documented with cljdoc. Things have mostly worked fine until the most recent release.

Joshua Suskalo17:11:59

The problem is that I (intentionally) require a namespace from a library I don't depend on.

Joshua Suskalo17:11:23

And I have it in a try/catch to detect if a given library is available, and automatically load some extensions if it is.

Joshua Suskalo17:11:34

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"

Joshua Suskalo17:11:01

One thing I'm going to try is to put no-doc on the namespace form that depends on the library

Joshua Suskalo17:11:23

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

Joshua Suskalo17:11:04

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: The require is in an ns which should not be read if the runtime is the jvm. my lib: 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:


@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.

Joshua Suskalo17:11:04

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.

Joshua Suskalo17:11:12

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

Joshua Suskalo17:11:28

I can try that next


@rahul080327 yeah, same issue here. Nice library btw!


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 ! And… ?