Clojurians Log v2

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?

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?

by :path do you mean paths to the git repo and stuff like that? on cljdoc this is inferred based on the source repository

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.

I mean the :paths returned by cljdoc which are returned for each var with analysis. There is a :filetoo. 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

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?

Yeah. I’d have to configure kaocha to exclude it somehow.

Easier to delete probably

feel free to delete, sure

ideally separate that in individual commits

The other confusion I had was project.clj. Do you make use of that in cljdoc/codox?

no, currently all we just rely on deps.edn

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 😄

Ok to delete project.clj to avoid maintenance confusion?

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.

BTW, thanks for your time and patience, very much appreciated!

clj is pretty neat and kaocha is well set up for it

You have been most helpful!

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! 🙂

What builds cljdoc/codox is my question I guess…

@lee there's a bit of trickery there. in the analysis-runner we construct a new process that contains the codox stuff.

@lee there's no build, it's added to the classpath via cljs git support

oh ho… that is tricky!

so if I write unit tests, I should probably write a circleci config to run them, eh?

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 😄

Tell you what, I can include the ci config and let you decide if you want to use it.

It just seems wrong not to…

I'll happily use it, just don't feel like you have to 😄

I’m obviously addicted to Clojure, might as well use my addiction for good.