This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-07
Channels
- # announcements (2)
- # beginners (25)
- # calva (16)
- # cljdoc (37)
- # cljsrn (24)
- # clojure (204)
- # clojure-nl (4)
- # clojure-spec (34)
- # clojure-uk (3)
- # clojurescript (13)
- # cursive (8)
- # data-science (3)
- # dirac (21)
- # figwheel-main (1)
- # luminus (3)
- # off-topic (45)
- # pedestal (3)
- # planck (2)
- # re-frame (5)
- # shadow-cljs (270)
- # spacemacs (5)
Oops, I just made my tests really carefully check that :path
is being generated correctly by codox. I then I see in cljdoc that :path
is stripped. 🤓 There is careful work in codox to handle the case where the :source-paths
are not the same as the project (or git) :root-path
. Am I correct in assuming these two are never different for cljdoc usage?
by :path do you mean paths to the git repo and stuff like that? on cljdoc this is inferred based on the source repository
I mean the :path
s returned by cljdoc which are returned for each var with analysis. There is a :file
too. The :path
really just a resolved :file
which handles the scenario where cljdoc config :source-paths
differ from cljdoc config :root-path
. I think maybe :path
did not make sense for cljdoc because it might have never been different from :file
… that and it is returned as a File… but that can easily be converted to a str.
We always want relative paths to the root of the directory that's being analyzed and I think with :file that has been easiest. I vaguely remember :path
being a thing but it didn't end up being useful for cljdoc
Could be misunderstanding — it's probably more than a year ago that I really worked on this code 🙂
The :path
generated is relative to project root. I think I see why cljdoc saw no value in it though. I will adapt to make sure :file
is relative to project root for cljs with my changes. This change might be valuable to weavejester, so I should be perserving that behaviour anyway.
Yeah, I’m sorry I am talking as if you have intimate familiarity with what is probably a fading memory for you! 🙂
No worries, happy to help if I can, just trying to manage expectations about my ability to do so 😄
I can see the benefit of keeping cljdoc/codox very similar to weavejester/codox so that merges back and forth are easy peasy. That said, what do you think of me deleting the cljdoc/codox writer/htlm.clj
?
If it's a burden, totally feel free to delete it. It hasn't bothered me so far but if it's in a single commit it will be easy to remove etc.
It is becoming one now that we have unit tests and it refers to deps we don’t include in deps.edn.
does the unit test tool try to load the namespace?
oh, probably when in watch mode, right?
feel free to delete, sure
ideally separate that in individual commits
no, currently all we just rely on deps.edn
Also, this is cool for me, I have only worked on lein projects to date, so I am learning about how things are handled without it.
clj
is pretty neat and kaocha is well set up for it
I am actually not sure how cljdoc/cljdoc brings in cljdoc/codox yet… but I can dig to understand… I think maybe I have monopolized enough of your day! 🙂
@UE21H2HHD there's a bit of trickery there. in the analysis-runner
we construct a new process that contains the codox stuff.
@UE21H2HHD there's no build, it's added to the classpath via clj
s git support
I'd say don't worry about that for now
We can always tackle that later and with the rate of change that's happening it's fine to run stuff manually for now.
If you want to do it that's cool too of course 😄
I'll happily use it, just don't feel like you have to 😄