Fork me on GitHub

@martinklepsch looks like it is possible to retrieve these libs;focusedCommentId=50308#comment-50308 unfortunately I'm behind a proxy at the moment so I can't test it reliably


Yeah I saw Alex’s updates and will take another look today. I was surprised though since we both seemed to reproduce this fairly reliably IIRC


The same for me 🙂


Issue is within cljdoc 😓


No worries, the important thing is that we were able to track it down

Daw-Ran Liou16:10:23

Hi everyone, I'd like to work on . What I learned so far is the server code is using pedestal to build the urls. Is it recommended to get familiar with the library before jumping into the issue?


Hey Daw-Ran, happy to see you'd like to contribute 🙂 For this issue the routing part actually isn't that important I would say but you should have a basic understanding of how interceptors work with pedestal:


It can also help to take a look at Pedestal's default not-found interceptor: and how it is used in Pedestal itself


You might notice that you can also pass a custom not found interceptor to Pedestal's default-interceptors function (it's in the same namespace).


We use this function in cljdoc so a good start might be to get up and running and make use of the option to supply a custom not found interceptor.


Would be happy to work through it together if you get stuck. Just let me know ✌️


oh and thanks again for the documentation fix 😊

Daw-Ran Liou18:10:26

Awesome! Appreciate your guidance. I'll start by understanding the interceptors. 🙂

parrot 4

@martinklepsch hello, I just had an idea, do you think would be feasable to add specs information to cljdoc? for example in Pathom I have a good number of functions that have specs for it (using s/fdef), I think could be useful to present these spec information with the docs for the fns, not sure how hard to get that in


This would be excellent of course. There are still some issues with the current Clojure.spec implementation that make this nontrivial unfortunately


I think we could fork clojure.spec and somehow enable this but it’s obviously not a very nice solution


yeah, I actually have done some inspection work in the past, but its not super reliable, I put some in a lib: it might be broken at this point


but it did some helpful things, like proper follow back the attribute definition chain (when you make a spec pointing to another one)


The issue is that we need to be able to tell which artifact a spec belongs to in order to store it in a database conflict free


yeah, and I can imagine a few complication cases, for example, spec lets (by design) you add specs to things that you don't own


Yeah that’s useful although I guess we would have to implement those things separately anyways since our data wouldn’t be in a runtime 🙂


so, imagine that I get a lib and add a spec for a fn of a third part library in my library


then the library adds its own spec for it, then how to know which one to keep?


actually, keep from the one that owns it, hehe, if you can easely detect it 😛


Since we only depend on the artifact under analysis you could (optimistically) assume that none of its dependencies modify this kind of Stuff


I need to update this issue though, i feel like it’s not properly describing the issue very well


But yeah, specs would be huge and we could do all kinds of cool stuff with them


yeah, it's exciting to think about the possibilities 🙂