Fork me on GitHub
#babashka
<
2022-06-06
>
borkdude16:06:09

So with the new bb CLI library in place, should bb have an -x mode where you can call single arg functions similar to clojure -X but with the more unixy style?

bb -x foo.bar/baz --skip --name foobar 
instead of:
clojure -X foo.bar/baz :skip true :name '"foobar"' 

2
1
🆒 2
borkdude16:06:26

I'm not sure how useful this would be since we also have tasks

teodorlu18:06:45

Seems like a nice addition to me. I generally prefer to wait until I have a specific use case before adding new stuff. I find it easier to judge whether it's a good solution then.

borkdude19:06:33

I'll probably wait with adding babashka.cli as a built-in until the nnext version

👍 1
borkdude08:06:46

Hmm, actually the nbb -x ... idea makes sense for nbb since it hasn't got a task runner and it's a cheap way to make CLIs

👍 1
perpen18:06:03

I'm looking for a simple (non-jvm) clojure code formatter, that I could plug into my editor - any suggestions? Maybe it's doable just using built-in bb functions?

lukasz18:06:22

We use a static binary build of cljstyle

borkdude18:06:39

@U03J48P76RW cljfmt also has a binary. but clojure-lsp can also be used as a binary CLI

borkdude18:06:44

clojure-lsp just uses cljfmt I think. cljstyle is derived from cljfmt if I'm not mistaking

lukasz18:06:21

Yes, cljstyle is based on cljfmt. I didn't know that clojure-lsp binary can be used for code formatting though

perpen18:06:09

Hmm I didn't think of using an lsp - they don't always work with kakoune (my editor), but I'll try that first, before the binaries you mention, thanks both

perpen19:06:01

It took me some time to realise that clojure-lsp works with my scripts, iff they have the .clj extension! Formatting works great, thanks again

borkdude19:06:18

@U03J48P76RW Doesn't it also just work when you enable clojure-mode?

perpen19:06:59

What's clojure-mode? An emacs thing? My editor is kakoune, I have a filetype but it doesn't seem transmitted to lsp.

ericdallo19:06:41

Never tried kakoune, but if it supports LSP it should work with clojure-lsp, LMK if need any help to setup the integration, we can also add a note on https://clojure-lsp.io/clients/

borkdude19:06:00

@UKFSJSM38 Does lsp depend on a .clj extension or does it work in emacs when you set clojure-mode regardless of the extension? (I know flycheck-clj-kondo does work regardless of extension)

ericdallo19:06:58

@U04V15CAJ it should not depend, but not sure if it works ATM, if not we should try to fix it

perpen20:06:12

But it could have a performance impact if it has to inspect tons of non ".clj" files in the directory

ericdallo20:06:00

No, this is something client does, not the server, your editor sends only the opened files, clojure-lsp then know what is your project and look for other clojure files

ericdallo20:06:22

If we add support for other files, it's only affected by the opened files

borkdude20:06:26

yes, for bb scripts etc it's usually only the open files that matter

perpen20:06:38

oh i see now, ok

breno1232118:06:12

Hie, It might me a dumb question but is it possible to run tests from a leiningen project using babashka? Or individual deftest from a lein project, instead of using lein test :only

borkdude19:06:54

@U027R1ML5RU Why would you not use lein? The alternative is to use deps.edn with e.g. the cognitect test runner. Calling this from babashka would usually be done in bb.edn tasks like this:

(apply clojure "-X:test" *command-line-args*) 

👀 1
breno1232119:06:48

Nice, the question was because lein sometimes takes a lot to load the dependencies and run the test and thought that maybe bb could help speed up for single test running 😊

borkdude19:06:45

@U027R1ML5RU I recommend doing this: Install neil: https://github.com/babashka/neil Either using babashka or via the clojure CLI And then invoke:

neil add test
It will add a deps.edn with the test runner. And then you can run clj -X:test to run tests

borkdude19:06:48

Or does your code run in babashka itself instead of the JVM?

breno1232119:06:40

Its a JVM normal project and I was trying to experiment with bb I'll give a look in neil Thanks!

chancerussell18:06:18

Kudos for babashka.process/exec—solves a wide class of problems I have for writing scripts around dealing with tons of AWS accounts :)

👍 2
chancerussell19:06:47

I think there’s something slightly hinky going on where the exec method of ProcessProperties actually wants you to provide the name of the program again as the first arg, C-args style, but I’m working around it by having my scripts just dupe the first item in the command list

borkdude19:06:39

Oh really, I didn't expect that

chancerussell19:06:50

$ bb -e “(babashka.process/exec [\“echo\” \“ok\“])” prints nothing

chancerussell19:06:03

bb -e "(babashka.process/exec [\"echo\" \"echo\" \"ok\"])" 
prints ok as expected

chancerussell19:06:30

I will try to nail it down later—it’s weird because some programs respond to that missing arg by printing their usage (like ls)

chancerussell19:06:37

so I’m not 100% sure that’s what’s up

borkdude19:06:15

maybe a bug in exec

borkdude19:06:19

I'll add some logging

borkdude19:06:20

I suppose you're right

borkdude19:06:44

@U03J48P76RW You also ran into this right?

perpen19:06:40

I did - but thought it unsurprising, as it's similar to the exec(2) syscall

borkdude19:06:31

I think it makes sense to change this behavior though

perpen19:06:53

hmm but then that isn't exec anymore

perpen19:06:26

but i guess ppl never use the feature anyways

borkdude19:06:34

is there a reason when you want to pass a different program name + arg0?

perpen19:06:04

not unless you're doing hardcore system programming i suppose

perpen19:06:43

iiuc, you have the file with the binary image, and the name that will appear eg in ps or when the process inspects its own args

perpen19:06:07

yes, change it

borkdude19:06:48

So maybe that's the 1% use case and we can have an option:

(proc/exec ["foo" ".."] {:arg0 "bar"})
or so?

perpen19:06:08

yes looks good

borkdude19:06:09

and arg0 defaults to "foo"

phronmophobic19:06:38

I saw this on the graalvm slack. Anyway, I know of at least one use case where you want a different program name than argv[0] , https://github.com/kovidgoyal/kitty/blob/c8c6f8691f4aa84f4d798428af268319b898798f/kitty/child.py#L257. It is pretty rare though.

perpen19:06:32

Ah yes, this one

phronmophobic19:06:36

It looks like you have a solution you like, but my philosophy for wrapping existing APIs is: 1. provide a wrapper that maps as close as possible to the wrapped function 2. provide a separate, convenience wrapper that uses 1) (preferably with a different, suitable name). For someone who is trying to actually do something tricky that targets the wrapped API, it's much easier to use a minimally wrapped version rather than try to figure out which flags and options you need to pass to a convenience to function to map back to some call the underlying wrapped API function.

perpen19:06:04

if we do want something more exec-like, the function could be (exec binary argv), eg (exec "/bin/blah" ["/bin/blah" "arg"]), and could have a variant of (exec ["/bin/blah" "arg"]) Not familiar with overloading in clj

borkdude20:06:35

yes, this is possible, but I think with the :arg0 overridable option you get pretty much the same

perpen20:06:52

it's simpler, and as long as the doc is correct..

borkdude20:06:37

We already have these overloads:

(exec [/bin/blah ...])
(exec [/bin/blah ...] {:env ..})

perpen20:06:16

arg0 consistent then, cool

borkdude20:06:07

ok, pushed the change to master now

perpen23:06:37

bb.process doesn't have anything like clojure.java.shell's with-dir and with-env, am I missing an alternative?

Bob B00:06:05

it's not precisely the same, but there is a dynamic *defaults* in the process namespace, so that could be altered or bound to assoc on any desired options

👍 2