Clojurians Log v2

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

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

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: https://clojars.org/rum - If you want to support my work on cljdoc you can sponsor me on GitHub: https://github.com/users/martinklepsch/sponsorship) For the entire first year GitHub will match your sponsorship! ‼️ 🙂

https://github.com/cljdoc/cljdoc/pull/301

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

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

yeah, so more choices for everyone

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

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

Wohooo! :)

Cool, after ingesting and preserving the sqlite data outside the container, and then running cljdoc, it worked 🙂 https://www.dropbox.com/s/3u4dm1timpi84b3/Screenshot%202019-05-24%2017.43.53.png?dl=0

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 🙂

I'm trying to follow the steps from https://cljdoc.org/d/cljdoc/cljdoc/0.0.1315-c9e9a7e/doc/running-cljdoc-locally. The muuntaja example works, but when I try to ingest my own lib, I get this during analysis:

Caused by: java.io.FileNotFoundException: Could not locate taoensso/encore__init.class or taoensso/encore.clj on classpath., compiling:(trident/util/core.cljc:1:1)

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
...

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?

You mean like actively scan in the background?

I mean scan when you visit e.g.:

<http://localhost:8000/versions/clj-kondo/clj-kondo>

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)

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

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

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

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

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

cool! thanks!

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

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

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

That's exactly right!

You need the pom for cljdoc to read the dependencies

: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

I think this is the relevant PR: https://github.com/cljdoc/cljdoc/pull/276

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