Clojurians Log v2

I dreamt about babashka last night :face_with_rolling_eyes:

Tell us more

Maybe it's a typo and he meant he dreamed about @borkdude

If you are using github CI the `setup-babashka` action now supports using CI builds from babashka in addition to normal releases: Example from the tests: https://github.com/turtlequeue/setup-babashka/blob/fff96c154d5aec91d5bbfbb201c5b20f96653084/.github/workflows/check_url.yml#L15-L17

Please note that if you are going to use links from CircleCI directly, these expire after a while, unless github caches these somehow. A workaround for this may be to make your own github project and upload the binaries under a release or something

cc @wilkerlucio

I dream about work all the time, but in weird ways that I work on a problem but it’s so separated from reality that it doesn’t work

in this case I had a dream that I was porting our makefiles to bb tasks

but something about one of the tasks that did something in real life?

Question, if I uberjar .bb scripts and I wanted to embed pod binaries in it as well would adding them to resources work and pods/load-pod be able to load from the resources?

@richiardiandrea afaik you can't load binaries from a .jar. most projects I know handle this by writing the binary to a temp directory first and executing it from there

I see, I liked the idea of self contained jars

but I guess that is a bigg-ish feature 😄

well, pods are OS-specific too, so you also have that issue

but it can be done using the way I described.

yep I am running in a container, I will just expose some sort of PODS_PATH env var

I’m seeing an issue with Babashka and protocol method implementations when I use the same name arguments in a multi-arity method implementations. Here’s an example:

Note that when some-protocol-method is implemented with the same named args (`, in this case as I’m ignoring the args) returns nil`, instead of the constant value passed into the constructor. When they’re named differently (`, and v`), it works as expected.

Thanks, looks like a bug to me!

Would you like me to drop this in an Github issue?

I will do it now

Awesome. You rock, @borkdude!

Thanks @borkdude

Did you notice the hand-written stamp?

Should be fixed on bb master

Did I mention you rock? 🎸

🤘

Thanks, @borkdude

The main open questions for "bb run": 1) Should :depends be dynamic? e.g. :depends (if (System/getenv "FOO") '[x y] '[x]) 2) (How) should (command line) args be passed down to dependent tasks? E.g.:

{x (println *command-line-args*) 
 foo {:depends [x]

bb run foo 1 2 3

...or wait until how we see how the new keyword argument map shakes out and changes programming habits

hint: I think it will make it even more data-centric

@heow yeah. btw, the latest bb already supports that keyword argument map thing (in most cases, fully when I bump clojure to its latest alpha). but even clojure -X:foo:bar:baz :foo 1 '[:bar :baz]' 2 is asking for some kind of "hide this behind a shortcut" solution

Btw, would it be wrong of me to bump clojure to the latest 1.11 alpha in bb for the keyword args map feature?