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:
<https://cljdoc.org/d/speculative/speculative/0.0.3?sha=>
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 đ