Fork me on GitHub
#babashka
<
2021-07-03
>
lspector02:07:59

What's the most elegant way to get the equivalent of something like ls *.log , with a result that is a sequence of the file name strings, in my babashka script? I tried using sh but couldn't make it work with the *. I resorted to the following which works but it seems like there must be a much better way:

(filter #(= ".log" (apply str (take-last 4 %)))
        (map #(.getName %) (.listFiles (File. "."))))

lspector03:07:12

Nice. So it seems the equivalent of the code I posted above, if I've done (require '[babashka.fs :as fs]), is:

(map fs/file-name (fs/glob "." "*.log"))

borkdude07:07:49

Yes or list-dir

👍 2
Helins12:07:40

I am preparing a monorepo where each subproject has its own bb.edn file. However, there are sets of useful tasks that I'd like to reuse in some of them. What would you recommend for avoiding any copy/pasting?

borkdude13:07:40

that's what I would recommend as well

Helins13:07:08

Indeed, that's what I have been doing but it still implies copying the tasks themselves, and if you change the :doc you have to do it everywhere, for instance. So it was getting messy.

borkdude13:07:19

Perhaps generate the tasks file using Selmer? perhaps a little hacky ;)

Helins13:07:32

All right, using the heavy artillery then 😛

Helins13:07:12

Related to previous but different. For very common tasks that end up pretty much in all subprojects (eg. test), I am trying to define them in my root bb.edn and specify a :dir when calling (clojure ...) (where a subproject lives and has its deps.ednfile). However I am having an issue with a dep that points to a :local/root:

Error building classpath. Manifest type not detected when finding deps ...
In spite of the path to that jar being correct. Doesn't happen when executing directly from the subproject dir

borkdude13:07:28

Does it happen when you use (shell {:dir ...} "clojure ...") instead? if not, then it might be a bug somewhere in bb

Helins13:07:58

It seems to work using shell, yes

Helins13:07:20

Yep, all is perfect from what I see

borkdude13:07:49

hmmm, can you make a repro for me? I can look into fixing it

Helins13:07:18

Sure if I manage to reproduce it 🙂

borkdude15:07:30

Is you can still reproduce it locally, it might also be a caching issue (in .cpcache)

borkdude21:07:23

This happens because the clojure task is a 2 step process: 1) deps resolved using tools.deps.alpha, 2) the actual clojure JVM process. But the options currently only apply against the second step where the process is launched.

borkdude10:07:33

ok, I think I fixed it on master. Could you try out a binary from master? Available in #babashka-circleci-builds in a few minutes

borkdude10:07:18

I'll add a test for it later

borkdude10:07:49

For me at least it works locally now:

[email protected] /tmp $ bb -e '@(babashka.deps/clojure ["-Sforce" "-M" "-r"] {:dir "proj1"})'
Clojure 1.10.1
user=> (require 'medley.core)
nil

Helins18:07:28

@U04V15CAJ Excellent, I'll give it a go tomorrow, thanks

Helins09:07:11

Seems to work fine now, REPL starts and classpath is properly computed 🙂

borkdude13:07:25

Haven't mentioned it here yet, but yesterday I made a CLI that exposes specter so you can use its DSL to filter/transform some EDN from stdin: https://github.com/borkdude/specter-cli/releases

😻 2
rwstauner18:07:20

is there a way to get the path to the currently in use babashka interpreter? something like $0? so that i could call the same bb to run a child script without needing it to be in $PATH ?

borkdude18:07:11

actually yes, let me look it up

rwstauner18:07:45

i looked in docs and checked (System/properties) but haven't found anything yet

rwstauner18:07:53

am currently trying to discover vars in the repl 🙂

borkdude18:07:02

@clj149

$ bb -e '(-> (java.lang.ProcessHandle/current) .info .command .get)'
"/Users/borkdude/Dropbox/bin/bb"

❤️ 2
borkdude18:07:25

Perhaps good to document somewhere

Cora (she/her)19:07:54

hmmm so I could combine jet with specter-cli to replace something like jq for manipulating json

borkdude19:07:21

@corasaurus-hex You could, but jet also already has a query language and the --func option for normal Clojure functions

Cora (she/her)19:07:46

oh! I didn't know it had that 😅

Cora (she/her)19:07:46

does adding specter to jet make sense?

Cora (she/her)19:07:46

I mean if making specter-cli made sense, meaning jet wasn't cutting it, does it make sense to add it to jet?

Cora (she/her)19:07:46

it's entirely possible i'm missing loads of context here

Cora (she/her)19:07:46

both are extremely cool

Cora (she/her)19:07:44

I just really can't wrap my head around jq's language for some reason

Cora (she/her)19:07:56

I have really really tried

borkdude19:07:46

Same here, that's why I just use jet with either --query or --func. I don't know yet about adding specter to jet, I actually am not that experienced with it, but someone in the #sci wanted it to use together with sci, so I made it work for that reason

borkdude19:07:18

it seems like a good candidate

Cora (she/her)19:07:38

I ought to sell my team on jet vs jq. we're a clojure shop anyways and our mildly complicated jq is basically unmaintaintable

borkdude19:07:24

cool. sometimes I also just use bb for json. some people have aliases for that (https://twitter.com/quoll/status/1401141320010420232)

borkdude19:07:35

I think @nate also shared one back in the early days where you could provide an expression, it's not so hard to figure out

Cora (she/her)19:07:57

a collection of jet & bb one-liners would be really cool

Cora (she/her)19:07:02

especially aliases

borkdude19:07:24

what you can also do instead of aliases is make an executable bb script and dump that in a bin folder

Cora (she/her)19:07:47

I have one of those for symlinking my dotfiles