Fork me on GitHub
Christian Johansen19:02:03

I looked through the docs I could find, and judging from the issues, it seems that it is not possible to exclude functions and namespaces from being documented?


You can add :no-doc metadata to the function or namespace you’d like to hide


If this is not part of the library authors guide linked on the home page please open an issue

Christian Johansen21:02:50

It was, sorry 😞 Can't believe I missed that


No worries! 🙂

Christian Johansen19:02:20

is there a reference for what can go in doc/cljdoc.edn somewhere?


No reference at this point but a good idea

👍 5
Christian Johansen19:02:15

I would like to exempt certain functions from the published docs. I also have namespaces that really exist just to share code between clj and cljs, and would like to not include them in the resulting docs

Christian Johansen19:02:08

one more question: it seems that docstrings from cljc files are duplicated - once as clj docstring and once as cljs docstring. is this by design or an unintended by-product?


Are you seeing them as different or are you asking about the internals of cljdoc and how stuff is stored

Christian Johansen21:02:18

I got the same docstring listed twice for every function in a cljc file


that's odd, have a link?

Christian Johansen21:02:24

no, it happened locally

Christian Johansen21:02:45

it doesn't seem to have happened on, so maybe there's some kind of accumulated state?


So usually the docstrings are only shown separately if they're different between platforms (clj/cljs)


I can't think of a reason why this would be different on

Christian Johansen21:02:04

I now see that there are minor differences - e.g. I fixed a link, and only one of the docstrings show the correct one

Christian Johansen21:02:42

could it be that when running locally, clj is taken from the jar, and cljs is taken from the git source or something?

Christian Johansen21:02:54

the cljs one is the most updated one

Christian Johansen21:02:05

this is very likely user error


both are taken from the jar


all vars/namespaces for a versioned artifact are wiped before "new" ones are imported so it should not be possible that one is updated and one isn't

Christian Johansen21:02:01

notice the link is fixed in the cljs version

Christian Johansen21:02:29

this docstring exists in a cljc-file, so somehow it ended up with a different version for clj and cljs


hm. I wish I had an explanation for that 🙂

Christian Johansen21:02:39

not a big problem. I would guess this resulted from multiple runs with the same parameters


Still not really possible in my mental model... if you end up understanding how to reproduce it, please share 🙂


Here's the code where old data is deleted before new data is imported

Christian Johansen21:02:12

very strange indeed... I just re-ran it and now I have only one string again, and the fixed links etc are gone 🙈


one thing that might make sense is to unzip your jar and take a look at the files inside. if everything actually ends up as cljc files and that the docstrings are as you expect

Christian Johansen21:02:53

I must have done something strange to the ingest script

Christian Johansen21:02:32

one more question while I'm on it - no matter what I pass to ingest --git I see this:

Christian Johansen21:02:35

INFO [2019-02-04 22:36:28,683] clojure-agent-send-off-pool-0 - cljdoc.analysis.git Cloning Git repo {:url null :revision master}


@christian767 this was a bug which has been fixed earlier today, can you pull and retry?


unfortunately the workflow described in "Running cljdoc locally" isn't tested in CI and so every now and then some change breaks things

Christian Johansen21:02:51

I understand. Everything else was a breeze to get up and running, so 👍 for this workflow

Christian Johansen21:02:03

yup, git repo picked up correctly

Christian Johansen21:02:41

btw the pack.alpha thing was solved. it was a case of trailing paths vs no trailing paths in the jar


yep, figured it out too 🙂


(by which I mean I noticed that a more recent version of pack.alpha works)


but that explanation sounds about right

Christian Johansen22:02:11

final question: when I run ingest with --jar /Users/christian/projects/mylib/myjar.jar it still looks up the jar from ~/.m2. does the jar have to live in ~/.m2?

Christian Johansen22:02:02

that was fast 🙂