Env/def does not persist vars with dots about env HOT 7 OPEN

Enqueued in my todo list

from env.

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

from env.

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).

from env.

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.

from env.

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...

from env.

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.

from env.

Sounds like a good idea to me 👍

from env.