Integrating Cloverage

[simon-brooke]

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]

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]

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.