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

Alex Miller (Clojure team)13:02:24

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.


not an official protocol. AWS has a few other protocols for similar reasons (with EMR specially): s3a and s3n come to mind.


so maybe this was only a wagon thing.


it looks like it's even gone from newer versions of Wagon


yeah iirc tools.deps used the s3 wagon until recently


oh no it's still there


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.

Alex Miller (Clojure team)17:02:50

s3p has never been a documented supported protocol for clj

Alex Miller (Clojure team)17:02:23

So was working before by accident, not by intent

Alex Miller (Clojure team)17:02:49

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