We should probably add docs that it's calling isSymbolicLink

https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#isSymbolicLink(java.nio.file.Path)

"...or it cannot be determined if the file is a symbolic link or not" Yep that's probably relevant WRT to hard links

Just updated quickdoc on fs with:

neil add dep io.github.borkdude/quickdoc --latest-sha --deps-file bb.edn

Ya, I think this makes sense. Feels like an essential abstraction along the lines of babashka.fs and babashka.process.

I have mixed feelings. In general I think anything vendored in needs to be both very feature complete but also somehow extensible. Once it's in, it's in for good. And it's very difficult to change. A project can continue to require an old dep, while a newer version of that dep breaks something moving forward. But an inbuilt library can never break its previous interface, or else you fork the language platform itself. Python has a lot of "batteries included" and a decade or two ago that was seen as a great thing, but over time they have come to be seen as less than ideal as they are essentially frozen in time (things like reading and writing Sun AU files are in there! https://docs.python.org/3/library/superseded.html). I am not familiar with java-http-clj. From the readme it looks very complete. Async. Websockets. Does java-http-clj work as a dep on babashka now? What is the downside of it being a dep that vendoring would solve? Also there would need to be a JVM babashka.http-client, just as there is a JVM babashka.process and babashka.curl. I have had some issues with babashka.pod calls where code containing direct calls won't compile on the main clojure (in this case to generate documentation with codox). Having code compilable by clojure can be useful even if it's not intended to be run there.

Well, I would vendor it as in: take the code and expose it under a different namespace and evolve it over time. Yes, the library would be able to run from clojure, of course. This has nothing to do with pods. It is similar to babashka.curl as a built-in, just based on the Java 11 client, which has better cross platform support has async options.

The reason for including it as a built-in it is that an http client is essential to bb scripting and that currently there are multiple choices of http clients, a messy state that I want to clean up

(I understand that its not a pod. Just noting that the presence of a babashka.pod/invoke line in a codebase prevents it compiling in clojure)

That's not necessarily true though, if you include the pod library?

anyway, let's not discuss pods here - that's not the point of this thread

yes, lets not derail

When you say a messy state you want to cleanup, you want babashka code by different authors that contains http interactions to look much the same?

No, I want to be able to point at one built-in solution that is the recommended http client. "How can I make requests in bb? Take a look at babashka.http-client . bb.curl: • Windows is always behind and the curl.exe doesn't even support compression, unless you upgrade it manually • One process per request can be way too heavy if you make many requests org.httpkit.client: • Holds entire response into memory at once, not suited for requesting or sending big files java 11 client: • Already supported in bb via interop, but no built-in Clojure wrapper which is what java-http-clj.core essentially is: a light wrapper that seems a good starting point

Ok I see. That makes sense. I think babashka.process is a similar story except with regards spawning processes, and that's inbuilt and is great. So if java-http-client is as great that would work as well inbuilt.

what about Hato? https://github.com/gnarroway/hato - I migrated one of our services to use it and it almost a drop-in replacement for clj-http (which is widely used on the JVM) and also doesn't depend on anything

it feels a tad more featured than java-http-client based on what I was looking for the other day

Hato does work from source in bb as well. But it caused me many problems trying to compile it to native image the other day. I think starting out with java-http-clj works better for this purpose and then we can incrementally add things to it which makes sense in bb

oh I see, I'm still super far from trying the native image compilation to work for any of our services, I wasn't aware of that

either way, +1 on having only one way of doing http in babashka - and just like bb/process and bb/fs it should work on the JVM (we use both extensively in some parts)

Given that the java.net.http stuff is already in babashka and is pretty durned easy to use from Clojure directly, I'd personally prefer we encourage people to use java interop. Any of the clojure wrappers I've seen are too opinionated; for one they encourage the idea that HTTP methods are verbs/functions rather than part of a data structure that is sent/invoked. java-http-clj.core does have send and send-async , but they're mentioned almost as an afterthought, not given pride of place up front. That's my 2¢.

The requests in typical small babashka scripts are mostly sync but having the option of async is great, this is why I think for typical scripts the java-http lib is a good fit, I think. Having a get function is just handy because in scripts that’s likely what you’re gong to use 80% of the time in my experience. For more advanced usage you still have interop available. Having a request function where you specify the method is also something that many of those other libs have.

Should I just delete the file in usr/bin and install via brew, or? Babashka is available via bb in the terminal, would I need to do something with PATH? (I'm not well versed in Linux.)

@U9CU2PQPM you can just remove the bb binary you have currently installed

And then re-install with brew

brew will probably add something to the PATH for you

Alright, thank you. 🙏

I think nowadays brew installs in /opt/homebrew/bin

could be different on linux

Worked wonderfully. 🎉 The new binary was stored in: /home/linuxbrew/.linuxbrew/bin

I think it only does /opt/homebrew for ARM macs

right, on my VPS it's also what Zeniten said