I guess it’s a jar file in the end so you can unzip it and take a look whats inside.

Oh thanks, is a JAR a zip under the hood?

What tool are you using to specify your dependencies?

yes, jars are just zips. If you rename it from foo.jar to foo.zip, you can just unzip it to see what's inside

Yes, JAR file is just an ordinary zip file.

Not 100% sure about uberjar thought, haven’t tested it.

If you're trying to find out which dependencies are contributing the most to your uberjar, I wrote small lib to help called https://github.com/phronmophobic/snowball

Leiningen @U2FRKM4TW

Or you can just run jar xf my-uberjar.jar.

@U4ZDX466T I saw that command yesterday but I don't have jar installed and can't find it in my OS package manager.

I guess it comes with JDK installation.

Yeah, it's included in the Java Development Kit.

oh, snowball doesn't work with lein projects directly

Try using lein deps :tree then. I don't think it will report the size of the dependencies, but it'll at least show why things are in the uberjar.

Ah OK, I'll reinstall openjdk, mine is probably ancient.

Thanks @U2FRKM4TW.

There's also lein deps :why some/coord where some/coord is group/artifact-id of a specific jar - it'll tell you why specifically that jar was included. And if you're still discovering things, I would recommend checking out tools.deps as well - i.e. Clojure CLI along with a deps.edn file instead of project.clj. It's overall simpler and more flexible, and for this particular task, you'll be able to use https://github.com/phronmophobic/snowball and https://github.com/clojure/tools.deps.graph with its size option.

Thanks, I've been meaning to check out tools.deps as everyone seems to be moving to it these days.

There is a workaround for using snowball with lein, https://github.com/phronmophobic/snowball#usage-with-lein-projects

@U03BA00LJ9L To be the naysayer, I haven’t noticed that 🙂 Of course here on Clojurians and the libraries closer to the core ecosystem are moving to those tools, but a few steps further away everyone still seems to prefer Leiningen, mostly because as a tool it is “a solved problem”. Optics, perspective, positive reinforcement, statistics…things like this can get complicated quite quickly.

What version of lein?

Would https://github.com/cognitect-labs/aws-api work in this case?

well I am aware of that but would i not be bringing in api's for all the aws services instead of just s3

although

{:deps {com.cognitect.aws/api       {:mvn/version "0.8.539"}
        com.cognitect.aws/endpoints {:mvn/version "1.1.12.192"}
        com.cognitect.aws/s3        {:mvn/version "822.2.1109.0"}}}

Yep, it's modular and rather small. But no clue about your specific needs - personally, I use it only for S3.

my need is basically to use storage but work for any platform instead of tying the library to a specific cloud provider

If conceptually S3 serves you, I'd definitely go with it - quite a few other providers have picked it up.

yeah it may be fine I will have to test, looking around not finding any uptodate alternatives anyway

seems this does not work overly well outside amazon ecosystem https://github.com/cognitect-labs/aws-api/issues/150

Yes, I'm familiar with how it works. I'm just looking for something to link to in a blog post that (also) discusses user.clj, really. 🙂

A rationale sorta thing, I guess.

Don't think I have anything you can point to

All right, thanks.

it is literally unmentioned in the reference section, I'll add a doc issue for that

Great, thanks! :thumbsup:

string or symbol?

string

(str (symbol kw))

I just happened to know there is also a

(.-fqn :foo/bar)

Maybe on Clojurescript, the other is a more portable solution

Oh, I see. So then is it safe to say that things like clojure.lang.PersistentVector implement Iterable since they have the iterator member?

yes, that's the only requirement

you just have an Iterable from some other source, not a type you're making yourself?

I’m writing a wrapper around some google Firestore code that returns a Iterable of documents in one of its functions. That part is straightforward; I’m also writing a mocked-up version that uses an atom for unit-testing code that interacts with the database.

iterator-seq is a tool for making a seq that wraps an iterator, but I think you want the reverse?

Exactly. I need to grab a node out of the mock db-atom and make it into something that implements Iterable. But if clojure.lang.PersistentList implements Iterable (like it sounds like it does) then I can just return (get-in @db-atom path) .

most seqs are Iterable so you're probably set in most cases just returning one

Thanks 🙂

I feel like it's been mentioned and someone is working on it? Maybe hit the search here

I imagine you'd need to get clojure as an official language in tree-sitter first?

afaik this is the most popular tree-sitter clojure attempt https://github.com/sogaiu/tree-sitter-clojure

apparently the scope is a problem due to supporting "higher level constructs" https://github.com/sogaiu/tree-sitter-clojure/blob/master/doc/scope.md

and of course Michiel has experimented with it https://github.com/borkdude/analyze-reify

Not surprised that he has hahah! I'll take a look around here and in those repos. Cant wait to spread myself thin with how much opportunity there is in the clojure DX effort !

oh wait there's #tree-sitter! It's not exactly pertaining to using it for GH DX, but prob a first order requirement to get to that anyways

I feel the issues they mention might not matter that much for just jumping around inside GitHub.

I think if you're talking about defs it probably will? I mean jumping around is usually "jump to definition" and "jump to references" and so supporting defs is required, I'd think?

Ya, I mean false positive around supporting it which they talk about.

$ clojure -M -e "(println Cloneable) (println Iterable) (println Runnable) (println java.lang.AutoCloseable) (println AutoCloseable)"
java.lang.Cloneable
java.lang.Iterable
java.lang.Runnable
java.lang.AutoCloseable
Syntax error compiling at (REPL:1:93).
Unable to resolve symbol: AutoCloseable in this context

Oh, it may just be anything newer than 1.6

Forgot these were brought in with that big map in clojure.lang.RT

Yeah, it's just missing. We have a patch for this, keep forgetting to get it in a release

slurp the stream?

Ah, nice! I see that in the notes now. I’ll give that a shot!

Hmm, no good. The slurp just returns a text-based rendering of the stream object: #object[java.io.PipedInputStream 0x37ca9a1c “.PipedInputStream@37ca9a1c”

...huh what

slurp should call http://clojure.java.io/reader https://clojuredocs.org/clojure.java.io/reader

which definitely supports an InputStream

I agree, it makes sense on paper. But I’m getting empty string content with no reflection warnings or exceptions, etc.

oh so with a PipedInputStream there is another thread dumping contents - maybe its a race condition?

Hmm. Not sure how to address that one. It’s a unit test, so even if the app spins off a thread, the response should still be on the original thread. At least that makes sense to me. If it’s not, I’m not sure what to try next.

So I found out I cannot slurp the stream from the response body returned during the unit test, but I can slurp from the stream itself if I break the ring-io/piped-input-stream call out into a separate function and return that in the unit test.