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

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

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

@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

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

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

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

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

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

ooor…. cljdoc should also take that into account 🙂

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 🙂

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

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.

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

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

yeah, this version is broken, sorry.

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

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

I agree with that

(which would also be properly supported by cljdoc)

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

works: https://cljdoc.org/d/speculative/kaocha-plugin/0.0.2-SNAPSHOT/doc/readme

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?

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

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

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

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

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

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?

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

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

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

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

ok, what about using a query param:

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

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

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

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

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

You too! :hugging_face:

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