Fork me on GitHub
#babashka
<
2022-02-04
>
David Pham15:02:49

Not a question for babashka in perticular, but I know I might find the answer here: I have an input stream, that yields me a json string per line and I would like to parse and transform it and send it to *out* , how would you do it?

David Pham15:02:12

I am using io/copy for now, but I don't know how I could have an intermediary step.

borkdude15:02:49

(binding [*in* (io/reader json-input-stream)]
  (loop []
    (when-let [line (read-line)]
      (do-something)
      (recur))))

David Pham15:02:26

Thanks a lot

borkdude15:02:34

or with cheshire, you can use parsed-seq directly to get a lazy seq of top level json elements

David Pham15:02:45

Thanks a lot! I would have search for a long time xD

🙌 2
rossputin16:02:26

Hi all - I’m trying to pull in and use Aero which is listed as a supported project - but I’m doing something wrong - when I’ve pulled in my dependency with (add-deps…) and required the library I’m getting a ‘No reader function for tag env’ which is in my config - any pointers? Thanks!

borkdude16:02:26

@rossajmcd where is that data reader normally defined? bb does not process data_readers.cljc but there is a way to set that manually

rossputin16:02:33

Without looking into it - I assumed it comes out of the box with use of the Aero library - I think in previous standard clojure usage that has been the case (though its been a while since I used it)

borkdude16:02:18

I was looking at their repo, but I could not see it

rossputin16:02:08

so for me - the only instances I have seen are in the edn config files I have previously used - no other setup required in my project(s)

borkdude16:02:53

can you post the bb script so I can try it

borkdude16:02:32

This works for me:

(require '[babashka.deps :as deps])
(deps/add-deps '{:deps {aero/aero {:mvn/version "1.1.6"}}})
(require '[aero.core :refer (read-config)])
(spit "/tmp/test.edn" "#env PATH")
(read-config "/tmp/test.edn")

🙏 1
rossputin16:02:17

hmmm - this is definitely on my end then - looking into ti

rossputin16:02:01

oh - sorry to waste your time - definitely on my side - my app is reading the config file for obvious reasons - and was unfortunately also reading it as part of some other functionality - my bad

rossputin16:02:55

thanks for confirming I was including the dependency correctly

jmv17:02:12

hello! i would like to move some of my graal projects to babashka since all that hard work has already been done and i can just benefit (thanks @borkdude!). are there any examples or caveats i should be aware of when distributing multi-file bb projects through something like homebrew?

👋 1
borkdude17:02:28

I recommend testing that locally :). I've recently been trying to make a multi-file brew package myself, based on how the clojure CLI does that

borkdude17:02:11

I have one shell script to place the bundled files in the install dir: https://github.com/babashka/obb/blob/main/script/brew_install.sh And here's a PR for the brew formula: https://github.com/babashka/homebrew-brew/pull/1/files

borkdude17:02:36

And then it's a matter of setting the classpath so bb will find those files correctly, too.

borkdude17:02:56

This is a bit complicated though. For neil, a CLI babashka script that I also distribute via brew, I just use add-deps https://github.com/babashka/neil/blob/65b5508a8496abe4d3a7168205b211760e9f4a8a/neil#L8 but this has the downside that the user must have Java on their system to fetch those deps the first time.

borkdude17:02:35

The first approach can also be done using an uberjar which contains all relevant resources and then you install that uberjar in the install dir and set the classpath to that uberjar.

borkdude17:02:26

bb sources.jar
also works btw, if you have made an uberjar with a -main function

🤯 1
borkdude17:02:50

creating an uberscript is the other option, this will create a single script from multiple scripts for deployment

jmv17:02:46

that sounds like it would work pretty well. not a big change from how it is now. thanks, i will read more in the docs on the uberjar approach!