Why is env mounted?

[Kalle Korhonen]

In the Luminus template env is a mounted state. What's the big idea with that? Personally, I think that's overuse of mount. I mean, you'd think that functions should be able to expect the env to be available at namespace load time. That's not the case if env is mountable (for example, in main, you specifically need to start env to handle migrations). That just seems to cause more problems than solves and causes issues for newbies like me before you understand what's going on. Nowadays, the first thing I do is to change the env to a a simple (def ...) and just reload the config namespace and re-start mounts if my config changes. So, basically just wondering if there's some grand idea behind it and if not, perhaps even suggest changing it in the template.

Kalle

[Dmitri]

My view is that the environment is a runtime resource. Using defstate for env ensures that this resource has the same behavior as any other resources. Functions that depend on the environment typically shouldn't be accessing it at compile time, so the fact that defstate  prevents this behavior is a benefit. Using defstate for the environment also ensures that it's restartable at runtime in production. You can connect to a running app via the REPL and reload the environment triggering a restart for any resources that depend on it.