👋

@borkdude thanks for all of the CLIs you've been putting out with graal.

has anyone tried to use environ with graal yet? no matter what I do, everything seems to be fully evaluated at compile time. i'd like to pull off what I do in Go/Rust (thinking 12-factor) and parse environment variables at runtime.

ignoring whether or not this is a good idea of course, if I'm instead using say, a config.edn file.

i'm wanting to put together a general configuration library a la https://github.com/spf13/viper

@gerred I just use (System/getenv), but you should not do this as a top-level expression, that will indeed be evaluated at compile time

got it. do you have an example somewhere?

https://github.com/borkdude/babashka/blob/master/src/babashka/main.clj#L184

oh interesting ok

it's interesting since environ's .cljc does boil down to System/getenv

but environ doesn't work and System/getenv does.

¯\(ツ)/¯

I don't know how environ works, but maybe it uses macros that are executed at compile time

it's using defonce on env.

maybe it's that.

https://github.com/weavejester/environ/blob/master/environ/src/environ/core.cljc#L80-L81

oh well, not needed for this library

the whole lib is simple enough to just....well, use the clj parts. 🙂

then I bet it's also not suited with AOT?

i bet not

it would be interesting to be able to use tools.deps to eventually re-def forms during AOT compilation. for example, in the Go project I work on, we set the version, git commit sha, etc., for our versioning at build-time with -X on ldflags: https://github.com/kudobuilder/kudo/blob/master/Makefile#L15

i see you're putting files in resources/ right now.

actually, I don't see why there can't be an alias with extra-deps that does that now without adjustments to tools.deps actually and just use interns or a build-metadata namespace :thinking_face:

if you compile your namespaces with the right environment variables set at compile time, that should fix it right?

if you want to capture some information from build time

oh sure

duh

😄