Fork me on GitHub

Hey! 馃憢 Any idea on why this doesn't work?

$ clj -e '(doc ns-map)'
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: doc in this context

Full report at:


You need to require clojure.repl, doc is defined there, not in core


user.clj requires clojure.repl for you


No, Clojure.main does this in the repl setup


I would guess it would be more correct to say that starting repl requires clojure.repl for you


I would guess even more correct thing to say that clojure.main/repl-requires are required when you start a repl


Quite right, I'm not sure why I thought otherwise. Brain fart.

Wes Hall13:02:45

Making some increasingly half-hearted attempt to get DynamoDBLocal running to start embedded for tests, but it seems to depend on sqllite4java which exists in the mvn repos but with <packaging>dylib</packaging>. Am I right in assuming that tools-deps doesn't have support for downloading dylib dependencies?


I prefer to use docker-compose to set up local service dependencies:

version: '2'
    image: 'dwmkerr/dynamodb'


but this is not related to #tools-deps this way

Wes Hall14:02:25

@thenonameguy Yeah, I will probably move to something like that. Dynamo local, at least in theory, does support embedded running so should be possible to throw up an in-memory version in a text fixture and tear it down afterwards, but the dependency on sqllite (and thus native libraries), is a bit of a hurdle. I'll probably give up, but just thought I would check that I am not missing a route I could at least try, but I think the docker-compose option is probably the way to go. Thanks.

Wes Hall14:02:11

Downloading native (thus platform dependent) libraries, is a bit awful anyway, I wouldn't be surprised if it's not supported.


@vlaaad @dominicm @alexmiller thanks for the help clearing that up! I realize why doc shouldn't work above, and I get the expected result when I require it as I "should" do.

$ clj -e "(require '[clojure.repl :refer [doc]]) (doc ns-map)"
  Returns a map of all the mappings for the namespace.


Not sure if this is a known regression or not鈥 but I was using some private S3 buckets as mvn repos; with a URL of the form s3p://<bucket>/<directory>/ I鈥檝e been using this for years (previously with leiningen) and found earlier in the week that I could no longer resolve deps via the clj tool. I suspect this was caused by the recent changes in t.d.a to using the cognitect aws lib; but I can鈥檛 be certain. Anyway I鈥檝e just tried changing the bucket URL鈥檚 to be of the form s3:// and it now works. No idea what the difference is in the protocols; but I鈥檝e seen both forms over the years.


s3p is for hadoop/presto it seems.


Alex did ask to know if anything broke. I think compatibility was the intention.


Yeah that鈥檚 why I鈥檓 mentioning it. The (end user) fix is trivial (just change to use s3://) once you know what the problem is though.


s3p has never been a documented supported protocol for clj


So was working before by accident, not by intent


s3p is an invention of the spring aws wagon


Ah interesting, I think I just copied my URLs from lein and didn鈥檛 think anything of it when they worked


Anyway it鈥檚 not a problem, I just thought I鈥檇 mention it incase it happens to others