Env/def does not persist vars with dots

[arichiardi]

For example, in:

(env/def
  database_jdbc.url "jdbc:postgresql://..."
  database_username "..."
  database_password "...")

The first env var in not present when I query it with (env/env).

[daveyarwood]

It seems like it would be tricky to support env vars with dots, as you can't define Clojure symbols in a namespace that include dots.

Interestingly, Clojure doesn't complain when you try to define such a symbol, but then it is not possible to retrieve the value of the symbol, at least not intuitively:

boot.user=> (def database_jdbc.url 42)
#'boot.user/database_jdbc.url
boot.user=> database_jdbc.url

clojure.lang.Compiler$CompilerException: java.lang.ClassNotFoundException: database_jdbc.url, compiling:(/var/folders/h0/jb2j4f310zx08ynwfxw8lxg00000gn/T/boot.user2431431541018554738.clj:19:1)
       java.lang.ClassNotFoundException: database_jdbc.url

[arichiardi]

That smells like the reason why I cannot see it in (env). However...what if you want to set properties, and you can with this tool, then you can definitely have dots (and cprop has rules to merge everything in a config map).

[daveyarwood]

OK, I'm following now. From googling, it does seem like including dots in Java system properties is a common thing to do, and it's definitely possible, at least, to set Java system properties including dots.

For env/def, perhaps we could establish some convention that dots will be replaced with (some character or string) in the symbols that it defines?

Something like:

(env/def database_jdbc.url "default-url")

database_jdbc.url       ;; ERROR
database_jdbc_DOT_url   ;; "default-url"

---

On an interesting note, it looks like currently, system properties including "." are intentionally omitted from (env), I imagine because they can't be retrieved as symbol names.

[arichiardi]

Yep you got it.

So database_jdbc_DOT_url would produce database_jdbc.url property? Or maybe we can replace = (allowed as a symbol but not as environment variable) with .

I agree it can be very confusing though...

[arichiardi]

Sorry my comment above was totally off. I'd suggest we add a warning in the else branch of that when (transforming it an if). Just to warn that the system property is there (in fact you can fetch it with System/getProperty) but it is left out intentionally.

[daveyarwood]

Sounds like a good idea to me 👍

[arichiardi]

Enqueued in my todo list