babashka 2023-05-17 | Slack Archive

Am i miss using the :dir option for babashka.process/process

this is my example output

(require
 '[babashka.process :as proc]
 '[ :as io])

(def proc1
  (proc/process
   {:out :inherit
    :err :inherit}
   "ls"))

(with-open [r (io/reader (:out proc1))]
  (println (line-seq r)))

(def proc2
  (proc/process
   {:out :string
    :err :inherit
    :dir "dir1"}
   "ls"))

(with-open [r (io/reader (:out proc2))]
  (println (line-seq r)))

mjhika04:05:47

i was having the issue in another bb project and was able to recreate it in a this small sample. I'm using babashka v0.10.163

pesterhazy04:05:35

That's very old – upgrade to the latest bb

👍 2

mjhika11:05:58

Oh goodness I didn't even realize that I thought it was the latest from brew :man-facepalming:

mjhika12:05:51

ok just wanting to confirm that was the issue. I guess i somehow downloaded that old binary and stomped on the one in my brew path. thanks for pointing out that very obvious problem to me 😆

👍 4

Edward Hughes10:05:03

Would anyone know how one goes about building java classes that aren't included for babashka(I assumed it would involve native-image somehow, but wanted to check I wasn't overlooking anything), and where to find a reference for what the sci-compatible subset of clojure is? My particular issue is needing to pull some of the future and promise objects out of clojure.lang which the library I am trying to compile for use with bb needs.

borkdude10:05:40

Those classes are in src/babashka/impl/classes.clj and building bb is a matter of running:

script/uberjar && script/compile

Also see https://github.com/babashka/babashka/blob/master/doc/dev.md

👍 2

borkdude10:05:41

and: https://github.com/babashka/babashka/blob/master/doc/build.md The GraalVM version mentioned in that doc should be updated to the newest

lread11:05:18

I think maybe bb is still on Graal 22.3.1 because 22.3.2 did not include a jdk19 variant.

borkdude12:05:53

true

chucklehead21:05:48

Trying to resolve a dependency issue with Recife and Clerk, would a PR to bump the version of fs used by babashka/process be welcome? Seems to pass all CI tests https://clojurians.slack.com/archives/C056HVC6Q3Z/p1684345272808769?thread_ts=1684339845.182149&cid=C056HVC6Q3Z

borkdude21:05:37

sure

borkdude21:05:36

bump to the newest please

chucklehead21:05:26

thanks!

borkdude21:05:01

ok 0.5.20 released

borkdude21:05:45

in general, if you need a newer version of a transitive dependency it is normal that you include the newer dependency yourself

borkdude21:05:41

but it doesn't hurt to bump things to the newer anyway

borkdude21:05:45

so thanks for the PR

chucklehead21:05:31

thanks, Recife uses process and I guess Clerk uses fs and needs a version with unixify so trying to run a notebook with recife was failing. I was working around with correct fs locally, but this seemed like the most straightforward way to fix it for the future.

chucklehead21:05:45

appreciate the quick response, 11/10 service as always

pfeodrippe21:05:58

Owww thank you!!!

borkdude21:05:08

yes, but if clerk includes a newer fs than recify, you should get the newer fs version automatically? unless you include an older one as a top level dependency (I'm assuming we're all using deps.edn and not lein here)

pfeodrippe22:05:51

Yeah, but I guess Chuckle (what’s your name? ahahahha) was using another library that included Clerk, then the dependency hell occurred. Thanks for updating it, Michiel o/

👍 2

2023-05-17

Channels