Fork me on GitHub
#babashka
<
2021-01-05
>
borkdude13:01:31

Just found a "bug" in babashka: it allows nested fn literals 😆

$ bb -e '(#(+ % (#(+ % 1) 2)) 10)'
13

😂 18
jeroenvandijk13:01:30

It makes you wonder why this isn’t supported in clojure itself 😅 although maybe better safe than sorry

didibus04:01:21

I think the reason are closures.

(#(+ 1 2 % ((fn [] %))) 3)
;;=> 9

didibus04:01:46

So in a nested scenario, the above would be amiguous:

(#(+ 1 2 % (#(identity %))) 3)
Like here, is the nested #() closing over the argument of the outer one? Thus the nested one is 0-ary and the outer one is 1-ary? Or, is the inner one a 1-ary function where we forgot to pass an argument?

lukasz15:01:36

First thing that comes to mind, it's hard to reason what to do with nested %

nate15:01:08

yeah, I think it would be easy to get lost in multiple levels

borkdude15:01:20

Same as (let [a 1] (let [a 2]))

nate15:01:37

the computer won't have a hard time, it's us humans that have limited computational ability

Dig16:01:42

is there a way to transfer system properties to pod? the issues came up with new aws pod usage. trying to use same method as in clojure. I could not use environment, since it is not settable inside the jvm, so the second auth is system properties that works well inside the jvm using aws-api. Another approach would be to set an environment variable for pod, is that possible?

borkdude16:01:02

@i.slack Are you referring to tzzh-aws?

Dig16:01:33

pod-babashka-aws

borkdude16:01:41

Ah right. Yes, it should pick up on (System/getenv "AWS_ACCESS_KEY_ID") (System/getenv "AWS_SECRET_ACCESS_KEY") environment variables.

borkdude16:01:02

ah sorry, now I read what you said

borkdude16:01:17

This is something we should support. Can you post an issue?

borkdude16:01:48

I think we can just pass those properties along to the pod

Dig16:01:17

yep, i will post the issue

borkdude16:01:31

@U0FT7SRLP ^ so we read the Java properties and then pass them as env variables to the pod, I think that might work

Dig16:01:11

https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html #2 will pick up system properties, so we can just transfer system properties if they are set

Dig16:01:43

this way we can leave env vars, since it is working right now

jeroenvandijk16:01:14

ah interesting find. Didn’t think about system properties. We need to implement the credential provider part to support these kind of situations i think

borkdude16:01:19

@i.slack System properties should be set at startup:

(load-pod ["pod-babashka-aws" "-Daws.foo=bar"])
or:
(load-pod ["clojure" "-J-D.aws.foo=bar" "-M" ...)
`

borkdude16:01:04

and it could copy the existing Java properties from the JVM (or bb properties), but this still needs some way of passing through the options manually?

borkdude16:01:48

What would be against just using env vars?

jeroenvandijk17:01:38

There are exotic situations where you want to use other credentials than the ones in the environment vars and override this with System properties, but I’m not sure if we should bother with that

borkdude17:01:13

If you want this, you can pass them manually like this:

(load-pod ["pod-babashka-aws" "-Daws.foo=bar"])

jeroenvandijk17:01:49

good enough i think

borkdude17:01:53

This won't work with pods from the pod registry though

borkdude17:01:01

as they don't have explicit arguments

Dig17:01:04

the env var take precedence over system properties, the only reason to use system props if it is all happening inside one jvm and cannot set env vars.

borkdude17:01:30

@i.slack But using the pod in the JVM is already a secondary use case compared to bb I think?

jeroenvandijk17:01:39

from my memory it was the other way around, but I’ll check

Dig17:01:06

yes, i am talking about pure aws-api in clojure vs bb in general

borkdude17:01:10

There might be a nice way to do this using a pod function:

(aws/set-credentials ..)
or something

jeroenvandijk17:01:27

yeah i think you are right. I’m trying to remember how I used system/properties before

Dig17:01:18

@U04V15CAJ the one potential problem with -Daws ... for credentials, is that they will be visible with ps -fe

jeroenvandijk17:01:25

Ah I did the opposite. I was using setProperty to set the default so it could be overriden by the ENV vars 😅

jeroenvandijk17:01:10

I think if we implement the credential provider this issue with properties will sort itself out i think

jeroenvandijk17:01:37

e.g. if no credential provider given we will forward the relevant system properties if set

jeroenvandijk17:01:45

(on client creation)

jeroenvandijk17:01:41

@U04V15CAJ So it would be a aws/client and aws/-client again

Janne Sauvala17:01:41

Is there a convenient shortcut to get the dir path where the bb script is that I’m running? If not, I could just use *file* and then just cutoff the script name from the path - maybe with Java’s File and .getParentFile

borkdude17:01:19

@janne.sauvala (System/getProperty "user.dir") or (io/file ".") probably works

Janne Sauvala17:01:10

The problem with (System/getProperty "user.dir") is that it prints the path where the script was executed. So if I’m not inside the same dir as the script it won’t work

Dig17:01:24

@Janne Sauvala (-> *file* io/file .getParent)

borkdude17:01:30

oh you want the directory of the script itself, yeah *file* is the one you need for that

Janne Sauvala17:01:07

Yes 🙂 @i.slack’s solution looks neat, thank you!

borkdude17:01:29

This one works too, but it longer ;)

(str (.getCanonicalPath (io/file *file* "..")))