Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating Cloverage #202

Open
simon-brooke opened this issue Jun 10, 2021 · 2 comments
Open

Integrating Cloverage #202

simon-brooke opened this issue Jun 10, 2021 · 2 comments

Comments

@simon-brooke
Copy link

Hi folks

I tend to use Codox and Cloverage together to document my projects, and this leads to two trees of HTML documents, one containing the documentation and one containing the test coverage data. For my own use I'm working on a patched version of Codox which will, I hope, show the test coverage data and passing/failing status on each namespace page (and as a stretch goal, under each function entry).

It's unlikely that I can make the integration seamless, since Cloverage is not intended to be used as a library. Instead, my current work is reading the output files from a Cloverage run (currently the coverage.xml file, but as that doesn't include passing/failing data, I shall probably have to web-scrape the HTML).

I'm working from version 0.10.7 of Codox pulled today. If I get this working in the next few weeks, would you be interested in a pull request?

And, while I have your attention, in codox.main/generate-docs you bind a let-binding options to a merge of the defaults and the passed in options. Would it offend you greatly if I did

(def ^:dynamic *options* default)

and then

(defn generate-docs
  "Generate documentation from source files."
  ([]
   (generate-docs {}))
  ([options]
   (let [options    (merge defaults options)
         write-fn   (writer options)
         namespaces (read-namespaces options)
         documents  (read-documents options)]
     (binding [*options* (assoc options
                                :namespaces namespaces
                                :documents  documents)])
     (write-fn *options*))))

This would enable my code to access options interesting to me, without having to pass them through your code all the way up the stack.

@weavejester
Copy link
Owner

It depends what exactly you have in mind. I don't want to put in something that scrapes from Cloverage's output in Codox, but I'd be open to more general mechanisms to draw in output created from other tools.

As for the binding, I'd need to have a very good reason to do it, as the code you have as an example looks like an anti-pattern. In general, there's a very narrow set of circumstances where dynamic vars are a good idea.

@simon-brooke
Copy link
Author

Noted. I'm trying an alternative approach – and note that the project parameter that you pass all the way up the stack essentially holds the run-time configuration, so will do that I need.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants