Fork me on GitHub
Slack Archive

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

2020-10-14

Channels

#cljdoc
<
2020-10-14
>
martinklepsch09:10:28

@miikka good morning, nice to see the sourcehut thing in production 🙂 what do you think about stripping the leading ~ from the username in the SCM link text? Since it’s not something users choose I feel it’s non-essential and almost like a detail related to sourcehut that isn’t very relevant

miikka09:10:37

:man-shrugging: I thought about it and decided to keep it since sourcehut keeps it everywhere, but if you feel like removing it is better, that's fine by me

lread12:10:23

I think both arguments are valid. (How helpful of me! simple_smile). We are linking to sourcehut and that’s the syntax they use for a repo. We are linking from cljdoc and its not the syntax it has used for all other repos.

miikka12:10:55

I admit it does look a bit weird

lread12:10:24

On coin toss things like this, I usually just go with what @U050TNB9F prefers. simple_smile

dominicm19:10:34

Fwiw, in the future there will be a syntax for groups which differs

dominicm19:10:11

~ for users and something else like + for groups. So it's useful in a sense for distinguishing.

martinklepsch11:10:50

That differentiation doesnt exist in the same consistent way across the different scm providers, which makes me feel it shouldn’t “leak” into cljdoc?

martinklepsch11:10:00

But idk, at the same time sourcehut repos aren’t going to be many for the foreseeable future so if sourcehut users consider the extra character useful I’m not gonna get in the way :)

dominicm11:10:19

Drew considers it significant. +cljdoc and ~cljdoc are completely separate.

👍 3
miikka07:10:18

Ah, I didn't know about this group syntax plan, but in that case I'd say let's keep the extra character in

👍 3
lread12:10:40

For the unaware, like me before googling, Drew is Drew DeVault, the person who created sourcehut.

martinklepsch10:10:12

@U09LZR36F @miikka let’s keep it in then :)

👍 3
timo11:10:18

Hi there

lread11:10:43

Hi @timo!

timo11:10:20

Is it possible to configure cljdoc? I need to avoid cljs analysis on cljc files in my project

timo11:10:36

it throws errors and I need to postpone that

lread11:10:03

We don’t currently have a way to tell cljdoc to ignore cljs files.

lread11:10:49

Are the throws due to something cljdoc might be doing wrong?

timo11:10:36

I am not certain, but the error might be on my side and it errors still if I put ^:no-doc on top

martinklepsch11:10:18

We can hardcode an exception if it’s not something that can be fixed on the side of the lib

martinklepsch11:10:06

Does the file work with the Clojure script Compiler otherwise?

timo11:10:08

we are working on cljs-compat right now so it might be broken for cljs currently, but that's beyond me

timo11:10:21

it's datahike

timo11:10:50

I would like to add only the api-ns

timo11:10:22

so I add no-doc everywhere and released a snapshot

lread11:10:23

no-doc just controls what parts of your api get exposed. Cljdoc will still load your entire project.

martinklepsch12:10:31

Yeah, and if a namespace required by the api ns can’t be loaded then that will also cause the api ns to fail to load

lread12:10:52

I wonder… have you thought about maybe keeping cljs work in a branch until it is ready for release?

lread12:10:18

Or does that not work?

lread12:10:20

Yeah I guess not. If you have cljc files. You are clj ready but not cljs ready… hmm…

timo12:10:33

yeah right

lread12:10:41

Personally, I think I’d just push through and get cljs side working before release. But that’s me. And maybe not what works for you?

timo12:10:46

as it comes from datascript mostly it was working once

timo12:10:09

that's actually not what I am working on

timo12:10:18

and I think it is a lot of work

timo12:10:39

so I just want to add the api-ns as docs

timo12:10:45

but I can find another way

timo12:10:26

thanks anyway

martinklepsch14:10:57

We can totally hardcode it if it makes your life easier, there’s a file that explicitly supports this kind of hard coding so it wouldn’t have any extra maintenance overhead

timo15:10:18

ok perfect. that would be cool for now. it will take a few weeks until clojurescript is restored I guess.

martinklepsch15:10:42

the hardcoding works based on group/artifact ID — which ones should cljs get disabled for?

timo15:10:10

io.replikativ/datahike

👍 3
martinklepsch16:10:19

Is there an issue to track cljs compatibility?

timo15:10:07

cool! thanks a lot. that version needs a few more no-docs though. but never mind