Fork me on GitHub
#babashka
<
2021-03-19
>
Jakub Holý (HolyJak)08:03:46

Any plans to add generators to spartan spec? I see there is already clojure.test.generators in bb.... ?

borkdude08:03:09

@holyjak Feel free to try to add them.

4
borkdude09:03:11

@holyjak There is also a library called https://github.com/green-coder/minimallist which should support generators, should also work with bb

❤️ 4
borkdude09:03:21

I didn't test it though

Dominik Mohilo10:03:10

Hi Gentlepeople, my name is Dominik Mohilo and I am editor for the GERMAN Java Magazine 🙂 I am looking for someone (apart from Mr. borkdude 😉 ) that would like to write an article (deadline. 16th of April) about Babashka for our German audience. Obviously it would be preferred when the article would be written in German, but this is not a must 🙂 Please write me a direct message or an email via <mailto:[email protected]|[email protected]> if you would be able to keep the deadline and are interested in writing 🙂 Hit me also up, if you'd be interested to write about Clojure in the future or about another topic 🙂 Cheers,

❤️ 8
pez10:03:51

Hopefully it will be written in English and published somewhere in that shape. 😃

truestory 4
Dominik Mohilo11:03:56

We will definitely publish the English version, too 😉

Dominik Mohilo11:03:17

Just not in printed form, unfortunately, but the most likely place for it would be http://jaxenter.com 🙂

❤️ 4
grzm15:03:50

Hola! I’ve got a cljc file that has babashka sections and jvm-clojure forms, and clj-bb-common forms that include symbols like *err* and pmap that aren’t available in cljs, so clj-kondo (and by extension clojure-lsp) complain about unresolved symbols. I’m not interested in using this namespace from cljs as all. What’s the common way of making the linter happy in these cases?

borkdude16:03:22

@grzm Good question. Can you try :cljc {:features [:clj]} in your config? I am experimenting with this, it's still undocumented and might change.

grzm16:03:04

To confirm, in the clj-kondo config?

borkdude16:03:35

This will cause the linter to ignore :cljs branches

grzm16:03:53

oh, nice.

grzm16:03:26

Yup, that works!

grzm16:03:00

Looks like it clears it up the emacs/clojure-lsp, too. So clojure-lsp is .clj-kondo/config.edn aware?

borkdude16:03:37

yes, it uses clj-kondo for its analysis

grzm16:03:31

Nice to confirm that the local config gets picked up, too. Thanks!

borkdude16:03:17

I am using it in babashka/fs myself

grzm16:03:52

Are there known issues using babaska pods on NixOS? I’m able to use pods on macOS but not NixOS. I can investigate further, but I wanted to know if this is a known issue before diving in.

grzm16:03:08

On macOS:

bb
Babashka v0.2.8 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (require '[babashka.pods :as pods])
nil
user=> (pods/load-pod 'org.babashka/aws "0.0.5")
#:pod{:id "pod.babashka.aws.credentials"}
user=> 

grzm16:03:28

On NixOS:

λ bb
Babashka v0.2.8 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (require '[babashka.pods :as pods])
nil
user=> (pods/load-pod 'org.babashka/aws "0.0.5")
java.io.IOException: Cannot run program "/home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws": error=2, No such file or directory [at <repl>:2:1]
user=> 
λ ls -la /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-rwxr--r-- 1 mglaesemann cloud_users 99238904 Mar  2 00:19 /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws

borkdude16:03:25

these pods are dynamically linked. Maybe you are missing libc++?

grzm16:03:39

That could be. I’ll track that down.

borkdude17:03:19

on the other hand, if bb itself runs, then the pod should also run I think

borkdude17:03:32

unless bb was built statically

grzm17:03:11

Looks like we’re using the dynamic release.

grzm17:03:59

babashka-0.2.8-linux-amd64.zip

borkdude17:03:24

what happens if you run /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws directly?

grzm17:03:41

Well, isn’t this interesting:

λ ls -la /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-rwxr--r-- 1 mglaesemann cloud_users 99238904 Mar  2 00:19 /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
17:05 mglaesemann@pair: ~
λ /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-bash: /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws: No such file or directory
17:05 mglaesemann@pair: ~[127]

grzm17:03:16

Someone’s lying to me.

grzm17:03:33

Something else for me to track down.

borkdude17:03:44

This is a message you get when the dynamically linked library cannot be found I think

borkdude17:03:17

I think you can see the list of required libs with ldd

borkdude17:03:55

$ ldd $(which bb)
	linux-vdso.so.1 (0x00007ffebb7c3000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4177d5f000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4177bdc000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4177bbb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4177bb6000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4177998000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f417798e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f41777cb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f417cd23000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f41777b1000)

grzm17:03:00

λ ldd /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
	linux-vdso.so.1 (0x00007ffffed1c000)
	libstdc++.so.6 => not found
	libpthread.so.0 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libpthread.so.0 (0x00007f094aea4000)
	libdl.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libdl.so.2 (0x00007f094ae9f000)
	libz.so.1 => not found
	librt.so.1 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/librt.so.1 (0x00007f094ae95000)
	libc.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libc.so.6 (0x00007f094acd6000)
	/lib64/ld-linux-x86-64.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib64/ld-linux-x86-64.so.2 (0x00007f0950d4c000)
17:08 mglaesemann@pair: ~

borkdude17:03:10

yeah, so it's libstdc++

grzm17:03:34

λ ldd $(which bb)
	linux-vdso.so.1 (0x00007fff895ad000)
	libstdc++.so.6 => /nix/store/hxs99j1kx878pxxw5lbdarml69r5f1qb-gcc-9.3.0-lib/lib/libstdc++.so.6 (0x00007fcee1fd8000)
	libpthread.so.0 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libpthread.so.0 (0x00007fcee1fb7000)
	libdl.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libdl.so.2 (0x00007fcee1fb2000)
	libz.so.1 => /nix/store/z39zr65hrbimzh40mxmdbpz64ma4b5vy-zlib-1.2.11/lib/libz.so.1 (0x00007fcee1f95000)
	librt.so.1 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/librt.so.1 (0x00007fcee1f8b000)
	libc.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libc.so.6 (0x00007fcee1dca000)
	libm.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libm.so.6 (0x00007fcee1c89000)
	/nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/ld-linux-x86-64.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib64/ld-linux-x86-64.so.2 (0x00007fcee6c7c000)
	libgcc_s.so.1 => /nix/store/hxs99j1kx878pxxw5lbdarml69r5f1qb-gcc-9.3.0-lib/lib/libgcc_s.so.1 (0x00007fcee1c6f000)
17:09 mglaesemann@pair: ~

borkdude17:03:35

but this is weird, since bb already uses that too

borkdude17:03:59

maybe this is because you are using nix

borkdude17:03:04

it has different dirs for every lib

grzm17:03:06

Yeah, but there’s the whole Nix layering stuff going on, too. I’ll ask some of our nix gurus.

borkdude17:03:44

this downloading of binaries is against the spirit of nix. maybe you should also build the pods using nix recipes. good luck ;)

grzm17:03:24

Indeed 🙂 One more thing to ask the nix gurus about :rolling_on_the_floor_laughing: Or, of course, it could be a learning opportunity

wilkerlucio17:03:50

I'm trying to make a small http-server using http-kit and babashka, but the process is quitting, how do I keep babashka alive?

borkdude17:03:05

@wilkerlucio @(promise) is what I usually do

💯 9
Jakub Holý (HolyJak)18:03:19

Hi! Can I distinguish whether a bb script is run from the command line (`bb -f`) or inside repl? Python has a nice trick for that and I believed bb as well but cannot find it now... 🙏

3
grazfather18:03:36

How do I tell emacs that my file that starts with a shebang (for bb) is a clojure file>

borkdude18:03:06

I don't know the solution in general though. why not just name it .clj?

borkdude18:03:31

Or .bb and then configure clojure-mode to be activated on that extension as well

grazfather18:03:07

because I want it on my PATH 🙂

borkdude18:03:13

so? I have lots of .clj files on my PATH

grazfather18:03:31

hl is a lot shorter than hl.clj

grazfather18:03:46

but the -*- thing works 🙂

grazfather18:03:30

I knew that was a thing, I’ve seen it a ton but I didn’t know its syntax nor its name to google

borkdude18:03:26

yeah, makes sense. I've been thinking about a task runner for bb projects. like:

bb hl
and then define in bb.edn:
{:tasks {hl {:task/type :babashka :args ["-f" "script/hl.clj"]}}}
but because I want to avoid conflicts with existing files, I am considering using keywords for task names:
bb :hl 
Would that be too ugly or awkward, or ok?

👀 3
grazfather18:03:00

yep, I was just thinking of writing my own. I like the ‘subcommand’ style of clis

grazfather18:03:08

bb :hl would be cool

borkdude18:03:43

bb :hl -p "foo.bar"
I thought it would maybe be awkward since keywords are often expected to be used in k/v pairs

grazfather18:03:25

it is strange when edn-style keywords make it to the shell

grazfather18:03:46

but i think it’s used in lein cli sometimes without a corresponding value?

borkdude19:03:11

true, also (require [foobar] :reload) is without corresponding value.

borkdude19:03:39

I think it would be kind of distinguishing to use keywords for this, since it's clear you are invoking a task

borkdude19:03:08

And I would then promote all of the other things to tasks as well:

bb :uberjar -m foo.bar

borkdude19:03:29

instead of:

bb --uberjar -m foo.bar

grazfather19:03:23

I am no UI expert but I prefer that

borkdude19:03:26

maybe there can also be a built-in bb :test like lein test

borkdude19:03:37

prefer that = which one?

grazfather19:03:40

go run go build go env etc

grazfather19:03:53

I am indifferent to whether : is in there

grazfather19:03:15

but if it’s a ‘task’ and you can’t run more than one than I think it’s better without --

borkdude19:03:17

there will also be a :do task which allows you to combine tasks, but the syntax for this is currently controversial:

bb :do :task1 arg1 arg2 :__ :task2 arg1 arg2

grazfather19:03:36

why :__ as the delimiter?

borkdude19:03:59

because I could not find another one, which one should I use?

grazfather19:03:04

I am not sure

grazfather19:03:31

-- often separates arg opts from opts to the script

grazfather19:03:37

i thought you were alluding to that

borkdude19:03:33

lein uses:

lein do task1 arg1 arg2, task2 arg1 arg2
yes, I am alluding to that. but -- might already be used by tasks?

borkdude19:03:53

as in task1 could also be using -- for its own parsing and then it would never see the remaining args?

borkdude19:03:01

or isn't this a problem...?

borkdude19:03:26

maybe it isn't

borkdude19:03:43

bb :do :task1 foo bar -- :task2 baz quuz ?

borkdude19:03:06

could also use :--

grazfather19:03:24

this is what I was hinting at

grazfather19:03:24
replied to a thread:could also use `:--`

this is what I was hinting at

grazfather19:03:57

You definitely are in a weird spot: You’re nesting tasks that can have their own arg parsing delimiters

grazfather19:03:29

so pretend I write my own docker exec in bb

grazfather19:03:44

You split the args from the container and the args to the exec

grazfather19:03:08

docker exec -it --rm ubuntu -- bash -c "/bin/sh" (don’t ask why i’d run that)

grazfather19:03:29

bb :do :exec -it --rm ubuntu -- bash -c "/bin/sh" :-- ...

grazfather19:03:48

-- as task delimiter wouldn’t work there

borkdude19:03:15

right {:docker {:task/type :shell :args ["docker exec"]}}

bb :do :docker -it --rm --ubuntu -- bash -c :-- :yolo

grazfather19:03:58

:-- seems reasonable. Have you ever seen it used in other clj/lisp cli contexts?

grazfather19:03:14

I think that basically you want something unique, obvious, and easy to type

borkdude19:03:18

no, maybe in prismatic schema, but there it is :-

grazfather19:03:49

but I would ask people who aren’t me ’cause I am new to clj/lisps

borkdude19:03:12

someone also suggested: :--/ok and :--/continue to indicate continue even when the previous task failed

grazfather19:03:21

or sacrifice that granularity (per task) and instead allow :cont as an arg taht must be before :do and apply it to each task

grazfather19:03:03

or something make-like: if the :task is actually :-task or similar it means allow errors

grazfather19:03:25

[graziano@gm-mbp:~/code/dotfiles/bin]$ make t
false
make: *** [t] Error 1
[graziano@gm-mbp:~/code/dotfiles/bin]$ make t2
false
make: [t2] Error 1 (ignored)
echo ok
ok
[graziano@gm-mbp:~/code/dotfiles/bin]$ \cat Makefile
t:
        false
        echo ok

t2:
        -false
        echo ok

borkdude19:03:32

that will make parsing more awkward, I prefer something more explicit

borkdude19:03:52

and works for most cases

borkdude19:03:10

and you can always use :--/continue if necessary

borkdude19:03:19

(or some better name)

grazfather19:03:22

Yeah. I just don’t like ‘smuggling’ out bb task context args in the middle of task args

grazfather19:03:59

idk if that’s the best word

borkdude19:03:15

I just don't understand what you didn't like. Be explicit please ;)

grazfather19:03:18

if you think of like lexical contexts I guess :--/continue leaks out of the task context

grazfather19:03:56

bb :do :task1 :t1a1 :-- :task2 :t2a1 :--/continue :-- :task3 :t2a1

grazfather19:03:39

between :task2 and :-- in my mind everything should apply to task2

borkdude19:03:55

no, this would be:

bb :do :task1 :t1a1 :-- :task2 :t2a1 :--/continue :task3 :t2a1

borkdude19:03:14

:--/continue is just a more special version of :--

grazfather19:03:15

ahh, I guess that is obvious, I misunderstood 🙂

grazfather19:03:25

yeah, that seems a lot more reasonable

borkdude19:03:45

from a distance, I'm not sure if this is too ugly though

grazfather19:03:04

I don’t imagine it would be used a ton

grazfather19:03:45

getting into the weeds, why / to delimit :-- from the ‘opt’?

grazfather19:03:27

we might be bike shedding

grazfather19:03:34

you’re pre-1.0 for a reason

grazfather19:03:51

if you choose one and people don’t like it, user your god given right to break backwards compatibility

borkdude19:03:53

sure, but this is never a popular thing to do ;)

grazfather19:03:23

yeah but I am shielded from that 😄

borkdude19:03:37

maybe I'll just keep this tasks idea very very basic

borkdude19:03:48

and then let it grow organically based on feedback

borkdude19:03:10

but bb :task kind of felt good to me

grazfather19:03:54

YAGNI is a good principle

borkdude19:03:57

maybe there will be somebody who reads all of the tasks from bb.edn and generates bash stubs for those in a bin folder ;P

borkdude19:03:05

so you can do $ task :P