Clojurians Log v2

I'm trying to work on a babashka script using CIDER. I've manually added a src directory to the classpath. How can I reload changed namespaces which are defined under src? none of cider-load-file, cider-load-buffer, cider-ns-refresh, cider-ns-reload, cider-eval-ns-form seem to reload the ns.under.src.dir namespace.

(require '[babashka.classpath :refer [add-classpath]])
(add-classpath "src")

(ns user
  (:require [ns.under.src.dir]))

ns.under.src.dir/some-new-symbol

(require ns.under.src.dir :reload)

sure, but that's not something u would want in production code, no?

you can do this from the REPL

or from a comment form

so currently i can only manually control reloading the dependent namespaces?

do you have many dependents?

in normal Clojure :reload-all also works, not sure if that is currently supported as well in babashka. this will cause all dependent namespaces to be reloaded

Not hard to support but might not be supported yet

we don't have a lot of code yet, but some of the code is used from both babashka and jvm clojure. it's just confusing to have different workflows and different dependency specification conventions, depending on the execution environment. im not the only one on the team, so we would need to explain this to 4 other ppl too.

feel free to create an issue about this, if this is something that can be improved in babashka(.nrepl)

No idea if this is babashka related, Admin can remove if it doesn’t belong. 😃

(.format (java.time.LocalDateTime/now)
         java.time.format.DateTimeFormatter/ISO_OFFSET_DATE_TIME)
=> clojure.lang.ExceptionInfo: Unsupported field: OffsetSeconds

not bb problem 😉

same would happen on jvm, but that format would work for e.g. `(.format (java.time.OffsetDateTime/now) java.time.format.DateTimeFormatter/ISO_OFFSET_DATE_TIME)`

or a ZonedDateTime

just those two afaik

I should have tried on JVM, but was in hurry. Thanks for helping me anyway!

:thumbsup:

My Google-foo is failing me - does bb include nrepl client? I know that there's a server implementation, but I can't find any reliable info about client support. I'd like to replace lein repl :connect ... with bb in some way.

@lukaszkorecki There is not a client, but there is a library which allows you to implement a basic one fairly quicky. https://book.babashka.org/#_interacting_with_an_nrepl_server

I am using the above in CI to execute commands against production ;)

I do have a natively compiled version of reply too, but this is just an experimental project.

securely, I hope 😉

Gotcha, let me check out the book link

yes, securely, it's within the same network let's say

and this script can be kicked off from TeamCity (CI)

Good! I'm prepping us for a security audit, so I'm a bit too paranoid these days. Re nrepl - most of the times we need to run a single command, but in some cases we need a full on connection to debug something in the live system, so I want to standarize our tooling and reduce its footprint (pulling a whole docker image with lein for this works, but is.... excessive)

I will invite you to my native reply repo as well, just in case

You should have an invite now

I think adding a basic nrepl client to babashka itself might be nice

for this purpose

but I guess you could also connect to the production repl from your local emacs / other via an ssh tunnel?

Technically yes, in practice - the company policy prohibits that (did I mention audits?)

Just got the invite, thanks!

yes. so the same developer can have access to this prisoned nREPL client box somewhere else? how is that more secure?

You have to jump through a couple of hoops to get to the machines which can start nrepl sessions. Now that I think about it - connecting from your local computer wouldn't work because we cannot open reverse tunnels in the first place.

(All of that is protected via AWS IAM and a bunch of other things)

ok. I am open to adding a basic nREPL client to bb if this would help.

assuming bb doesn't have to carry a ton of extra deps for this, it will be more like the above script, but better executed and built in

Let me check out reply-cli - if it can do both interactive sessions and one-off evaluations it might be better than bundling the client with bb

ok

I haven't published reply-cli publically because I hacked the code as quickly as I could to a working state

Makes sense!

most notably I changed futures into delays in the completion code

because spawning futures at compile time isn't something GraalVM likes

I'll check it out and report back :thumbsup:

A new version of sql pods is out. This release adds better support for inserting and retrieving arrays. https://github.com/babashka/babashka-sql-pods/blob/master/CHANGELOG.md#v003 Babashka sql pods allow you to interact with databases like PostgreSQL, Oracle and MS SQL

What is a pod in the babashka context?

@anders152 Pods are binaries that expose library functionality to babashka via RPC

It is like shelling out but more integrated, so you can just do function calls without having to do de/serialization yourself

See https://github.com/babashka/pod-registry for a list of available pods and examples

Interesting concept! How did you land on this type of design?

I want to be able to add features to babashka without bloating the binary too much with stuff that isn't used widely. You can either do this via libraries (I might implement the nREPL idea using a library instead), but bb libraries have the limitation that you can not access Java classes that aren't available in the bb image. You can also shell out to other binaries via clojure.java.shell or babashka.process, which works well, but is sometimes cumbersome. Also I had some ideas about FFI but this is not very extensible from the Java side (yet). So babashka pods are a kind of higher level FFI (with more overhead, e.g. we serialize args via json or transit, RPC-style) but it works well and performance is generally fast enough for scripting tasks.

is it possible to use pods in clojure code? or are they bb only?

i really like bb/fs

bb/fs is not a pod, but just a library. you can use that in Clojure as well. But pods are also runnable in Clojure using the pods library (https://github.com/babashka/pods)

thank you!

Thanks a lot for the explanation @borkdude! As always Clojure culture seems to favour real-world pragmatism. I love it!

I found this one easy to read and understand (though that’s probably because I mostly write Go) https://github.com/babashka/pod-babashka-go-sqlite3/blob/main/main.go

very simple: Read from stdin, process the message, switch on the Op