Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-02-04

Channels

#cljdoc
<
2019-02-04
>
cjohansen19: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?

martinklepsch20:02:27

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

martinklepsch20:02:46

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

cjohansen21:02:50

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

martinklepsch21:02:48

No worries! 🙂

cjohansen19:02:20

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

martinklepsch20:02:02

No reference at this point but a good idea

👍 5
cjohansen19: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

cjohansen19: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?

martinklepsch20:02:50

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

cjohansen21:02:18

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

martinklepsch21:02:42

that's odd, have a link?

cjohansen21:02:24

no, it happened locally

cjohansen21:02:45

it doesn't seem to have happened on http://cljdoc.org, so maybe there's some kind of accumulated state?

martinklepsch21:02:58

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

martinklepsch21:02:47

I can't think of a reason why this would be different on http://cljdoc.org

cjohansen21: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

cjohansen21: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?

cjohansen21:02:54

the cljs one is the most updated one

cjohansen21:02:05

this is very likely user error

martinklepsch21:02:19

both are taken from the jar

martinklepsch21:02:31

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

cjohansen21:02:53

here's an example

cjohansen21:02:01

notice the link is fixed in the cljs version

cjohansen21:02:29

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

martinklepsch21:02:43

hm. I wish I had an explanation for that 🙂

cjohansen21:02:39

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

martinklepsch21:02:55

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

martinklepsch21:02:44

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

cjohansen21: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 🙈

martinklepsch21:02:28

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

cjohansen21:02:53

I must have done something strange to the ingest script

cjohansen21:02:32

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

cjohansen21: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}

martinklepsch21:02:11

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

martinklepsch21:02:09

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

cjohansen21:02:51

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

cjohansen21:02:03

yup, git repo picked up correctly

cjohansen21:02:41

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

martinklepsch21:02:00

yep, figured it out too 🙂

martinklepsch21:02:18

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

martinklepsch21:02:25

but that explanation sounds about right

cjohansen22: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?

cjohansen22:02:02

that was fast 🙂