Fork me on GitHub
Adam Helins09:10:38

Is it worth documenting babashka.fs/sym-link? only works on soft links or is it common knowledge?


We should probably add docs that it's calling isSymbolicLink

Adam Helins09:10:56

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


I'm considering vendoring and start the babashka.http-client built-in namespace based on this. Why vendor? An http client is essential to babashka and I want to have a single namespace I can point people to instead of choosing between bb.curl / org.httpkit.client / clj-http-lite / etc. while also having the flexibility and freedom to add or improve UX / compatibility with bb.curl, while not depending on more third party libs in bb Having the namespace as babashka.http-client makes it also easier to find than java-http-clj.core inside of bb. The old options will still remain available of course, for backwards compatibilty and you can still run java-http-clj.core as you can today. Thanks for the awesome work on that lib @schmee. If any of you have any thoughts, respond in 🧵

👍 1

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

Lars Kristian Maron Telle11:10:50

I'd like to use Homebrew to manage my Babashka installation. I currently have an installation, and I think I used the installer script to install that one. My installation resides in /usr/local/bin. I'm on Ubuntu. I'd like to remove my current installation and reinstall using Homebrew, which I have ready to utilize. How should I go about doing that?

Lars Kristian Maron Telle11:10:24

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

Lars Kristian Maron Telle11:10:05

Alright, thank you. 🙏


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


could be different on linux

👍 1
Lars Kristian Maron Telle11:10:23

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

👍 2

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


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