cljdoc

https://cljdoc.org/ & https://github.com/cljdoc/cljdoc
borkdude 2019-02-08T09:37:46.117600Z

I tried to run cljdoc on the speculative kaocha plugin for which I just made a release, but it failed: https://circleci.com/gh/cljdoc/builder/1511

borkdude 2019-02-08T09:37:59.118Z

This is the repo: https://github.com/borkdude/speculative-kaocha-plugin

borkdude 2019-02-08T09:39:58.119Z

I suspect this is because I called my test profile kaocha instead of test (but this was suggested in the kaocha docs 😞)

martinklepsch 2019-02-08T09:54:40.119600Z

@borkdude cljdoc doesn't know about profiles. The only thing it looks at is the .pom file: http://repo.clojars.org/speculative/kaocha-plugin/0.0.1/kaocha-plugin-0.0.1.pom

martinklepsch 2019-02-08T09:55:07.120400Z

In this case the kaocha.plugin namespace is missing, most likely because the kaocha dependency is missing.

borkdude 2019-02-08T09:55:11.120600Z

I thought it includes deps from the test profile in cljs analysis

martinklepsch 2019-02-08T09:56:02.121200Z

It includes dependencies with the :scope "test" listed in the POM file

borkdude 2019-02-08T09:57:17.121900Z

right, and that happens automatically when you use the name test as the profile

borkdude 2019-02-08T09:57:27.122200Z

so I shouldn’t have named it kaocha like kaocha suggested…

borkdude 2019-02-08T09:57:49.122500Z

ooor…. cljdoc should also take that into account 🙂

martinklepsch 2019-02-08T09:58:42.123900Z

cljdoc won't look at build tool specific files, just not feasible to support a matrix of build tools efficiently and POM files are universally agreed upon 🙂

martinklepsch 2019-02-08T09:59:20.124600Z

but that observation about test profile deps being added to pom.xml would be good feedback to the koacha authors

borkdude 2019-02-08T09:59:40.125Z

OK, then I think kaocha should change this in their docs if they want it to work properly with cljdoc. Either way works for me.

borkdude 2019-02-08T10:00:05.125600Z

But this version won’t appear on cljdoc, I guess we’ll have to wait until the next one

martinklepsch 2019-02-08T10:01:03.126200Z

If you end up opening an issue about this feel free loop me in/mention me

martinklepsch 2019-02-08T10:01:34.126600Z

yeah, this version is broken, sorry.

borkdude 2019-02-08T10:01:53.127300Z

ah wait, I think kaocha does this because test is an already existing profile in leiningen

martinklepsch 2019-02-08T10:02:04.127600Z

One could also argue that you could specify those deps with :scope "provided" since this library assumes kaocha has already been pull in through other ways

borkdude 2019-02-08T10:02:14.127800Z

I agree with that

martinklepsch 2019-02-08T10:02:29.128100Z

(which would also be properly supported by cljdoc)

borkdude 2019-02-08T10:06:47.128300Z

This should work then: https://github.com/borkdude/speculative-kaocha-plugin/blob/master/project.clj#L10

borkdude 2019-02-08T10:19:50.130200Z

Since I had the problem yesterday (even after we discussed this), that I released a version and then noticed I forgot to update something in the RELEASE notes, and other people ran into this as well: Maybe there can be a mode for cljdoc where the Markdown/Asciidoc files are updated from the most recent ones, but the code analysis is immutable?

martinklepsch 2019-02-08T10:20:40.130700Z

@borkdude did you read the disscussion here: https://github.com/cljdoc/cljdoc/issues/31

borkdude 2019-02-08T10:23:15.131400Z

That’s what I referred to yes, sorry for being unclear. {:cljdoc.doc/versions {"0.3.4" "d5717d6659c37aa06ba25336aa994bd21b1b3d5a"}} seems like a plan

borkdude 2019-02-08T10:24:25.131900Z

I understand that this is hard and must be carefully considered. Just pointing out it’s a feature I think is valuable 🙂

martinklepsch 2019-02-08T10:26:37.132500Z

Appreciate the feedback and definitely see that this is a common pain point for cljdoc users.

martinklepsch 2019-02-08T10:26:55.132900Z

What do you think about the tag approach, i.e. you'd tag a commit with cljdoc-$VERSION

borkdude 2019-02-08T10:27:55.133500Z

From a UX standpoint which one would be better? Maybe the tag, because you don’t have to create another commit just for cljdoc to pick it up?

borkdude 2019-02-08T10:28:28.134100Z

I’m not sure if it matters much, either way will work for me as a user

borkdude 2019-02-08T10:30:31.134500Z

or maybe library users should have to be able to login to cljdoc so they can change the SHA manually over there if needed?

martinklepsch 2019-02-08T10:31:39.135Z

nah, I don't think we want to maintain users/sessions/passwords/...

martinklepsch 2019-02-08T10:31:54.135600Z

at least not for such a feature which only affects a minority of users

borkdude 2019-02-08T10:32:17.136Z

ok, what about using a query param:

<https://cljdoc.org/d/speculative/speculative/0.0.3?sha=>

borkdude 2019-02-08T10:32:59.136900Z

You could spoil the docs of another project this way without some form of protection, so then the tag or edn config would be better

martinklepsch 2019-02-08T10:33:12.137200Z

docs are built beforehand so providing a sha when requesting them is too late

martinklepsch 2019-02-08T10:33:48.138Z

if you have alternative proposals to the ones already mentioned in that issues, please leave a comment there so they don't get lost in the Slack stream

borkdude 2019-02-08T10:34:17.138600Z

I thought it’s done on demand: when it doesn’t exist, it gets built. You could do the same with the SHA: if it’s already built against a different SHA, refresh it

borkdude 2019-02-08T10:40:33.140400Z

Done. Have a nice day and thanks for all the hard work.

martinklepsch 2019-02-08T10:44:05.141400Z

You too! :hugging_face:

martinklepsch 2019-02-08T10:48:36.141700Z

If anyone is keen to do some code review: https://github.com/cljdoc/cljdoc/pull/264 🙂

👍 1
✅ 1