Fork me on GitHub

nice work on the Docker image. I’ve been able to run it like this:

docker run --rm -p 8000:8000 cljdoc/cljdoc:0.0.1406-030763c
it’s probably still undocumented? it would be nice to have some pointers around: persisting state, importing local docs


the DB migration could probably happen at build time, so it would save time at startup


(nothing urgent, I was just playing with it)


@borkdude yeah, that could probably be documented better


I'm not entirely sure where it should go (maybe into running cljdoc locally) but if you put up the rough steps and instructions I'm happy to fill in any blanks that aren't clear


I think “running cljdoc locally” makes sense yeah. Docker would probably be my first goto instead of trying to build all these npm deps


I’ll first make an issue for this, so we can think about it a little bit


should be just npm i; npm package or something right?


yeah, but that requires npm, which not everyone uses (really, some people don’t do anything with front-end or JS). I think Docker is the path of least resistance without cluttering your machine with stuff


Of course, some people don't want their machine cluttered with docker


yeah, so more choices for everyone


We can also discuss the details in a PR, I think it would be fantastic to have a first cut that can be iterated upon 🙂


Also... two small "announcements": - cljdoc is now linked to from every Clojars artifact page: - If you want to support my work on cljdoc you can sponsor me on GitHub: For the entire first year GitHub will match your sponsorship! ‼️ 🙂

🎉 8

(the branch allows edits from maintainers, so feel free to push to this PR)


I’ve got something going:

docker run --rm -p 8000:8000 -v $HOME/Dropbox/dev/clojure/clj-kondo:/clj-kondo --entrypoint "clojure" cljdoc/cljdoc:0.0.1407-32d00ce -A:cli ingest -p borkdude/clj-kondo -v 2019.05.20-alpha-SNAPSHOT -g /clj-kondo
but it complains about :cause Requested version cannot be found in configured repositories: [borkdude/clj-kondo 2019.05.20-alpha-SNAPSHOT] Not sure what this is.


it probably needs the jar to be in the .m2 directory? I’m not sure why since I’m ingesting a git repo?


this didn’t help:

docker run --rm -p 8000:8000 -it -v $HOME/Dropbox/dev/clojure/clj-kondo:/clj-kondo -v $HOME/.m2:/root/.m2 --entrypoint "clojure" cljdoc/cljdoc:0.0.1407-32d00ce -A:cli ingest -p borkdude/clj-kondo -v 2019.05.20-alpha-SNAPSHOT -g /clj-kondo


I’ll continue some other time


Jars are always used for analysis. Git is only used for articles. Sorry for being terse, afk


ah now I get it


Try mounting your m2 into docker as well


yes, that’s what I did, but I got my version wrong I think


cool, it worked


Cool, after ingesting and preserving the sqlite data outside the container, and then running cljdoc, it worked 🙂


I’ll update the docs later, but it’s already described in the PR


am I right that cljdoc does not scan your local m2 directory for newer versions? if that were possible, then I could just ingest after I started the server, using the UI 🙂


You mean like actively scan in the background?


I mean scan when you visit e.g.:

Jacob O'Bryant16:05:01

I'm trying to follow the steps from The muuntaja example works, but when I try to ingest my own lib, I get this during analysis:

Caused by: Could not locate taoensso/encore__init.class or taoensso/encore.clj on classpath., compiling:(trident/util/core.cljc:1:1)
Earlier in the analysis output, I see:
Used dependencies for analysis:
org.clojure/clojure 1.9.0
  org.clojure/core.specs.alpha 0.1.24
  org.clojure/spec.alpha 0.1.143
trident/util /home/arch/.m2/repository/trident/util/0.1.1/util-0.1.1.jar
org.clojure/clojurescript 1.10.339
So my lib (`trident/util`) is included, but taoensso/encore (which my lib depends on) isn't. I'm assuming encore should be listed here, is that correct?

Jacob O'Bryant16:05:19

I would think the dependency on encore would've been picked up from the pom file, but apparently that's not happening. A difference I noticed between my lib and muuntaja is that the jar for my lib doesn't have anything under META_INF, so maybe cljdoc/codox depends on certain files being in there?


Dependencies are extracted from the Pom so if it’s in there it should be picked up


I’m away from the computer right now but happy to help you out later

Jacob O'Bryant16:05:48

k thanks. I'm putting together a minimal example now and I'll let you know if I make any progress

Jacob O'Bryant17:05:20

Got a minimum example up here: That repo packages and installs the same way that I do for trident/util (i.e. with deps.edn, juxt/pack.alpha and deps-deploy), so I'm guessing it has something to do with that


Hello, will fix anything that needs fixing 👋


I guess we need to see the pom.xml for trident.util :)


If you run jar tf myjar.jar that output is useful

Jacob O'Bryant18:05:40

I actually just figured out the problem! if you include META-INF/pom.xml in the jar it works

Jacob O'Bryant18:05:01

not sure if this is expected behaviour or not (@U050TNB9F?)


That's exactly right!


You need the pom for cljdoc to read the dependencies

Jacob O'Bryant18:05:04

:thumbsup: Before I was assuming that the pom at (e.g.) ~/.m2/repository/io/dominic/super-duper-octo-barnacle/0.1.3/super-duper-octo-barnacle-0.1.3.pom would be used


thats interesting, i think there was a PR recently that changed this, focusing on the Pom in the jar and not so much on the other Pom


I see, interesting


I would have thought they were equally valid?


They are but tools deps supports resolving deps via a jar only too and so I think we switched to that. You can probably dig up the PR very easily


Please open an issue if the behavior discussed here should be considered a bug! :)


So the behaviour is this way because it allows building jars locally?


not sure I understand 😄


What we did before was just use :mvn/version and add that to the classpath. But when users passed a custom jar location (ie. something that would not be found when using :mvn/version) that caused problems. So now instead of depending on tools.deps to find the right jar we depend on the actual jar file the user provided:


tools.deps supports resolving dependencies for jars like this (at least in the limited testing we did) and generally most libraries seem to be packaged in the way that is compatble with the way tools.deps handles this


Maybe it would make sense for tools.deps to surface an error or warning if it can't resolve transitive dependencies of a jar but not sure


Seems like there's multiple ways the pom can be found in different contexts


A general remark about the scripts in cljdoc: it would be a lot easier if you assume that people will call the scripts from the root dir I think? No need to worry about ../.. and doing things like cd $(git rev-parse --show-toplevel)


but maybe there are reasons that it doesn’t work like that


I updated the PR now, I think it’s pretty much ready 🙂


one assumption in the updated README is that there is a Docker image with a latest tag on Dockerhub. I also updated the config for that


cool to see docker option for testing locally! Is using docker locally a better option if I want to more closely match what happens in cljdoc production?


I think it’s pretty much the same thing?


Yeah, same thing

🤓 4

cool! thanks!