Consider removing the ENV[] = in favor of a new setup

[jwoertink]

LuckyEnv currently reads your .env file, then appends all of the key/values in to Crystal's ENV constant.

lucky_env/src/lucky_env.cr

Line 99 in ea76de6

ENV[k] = v

Then in your Lucky app, you can just sprinkle your ENV["WHATEVER"] all over your app.

However, in a recent forum thread and in this PR (related: crystal-lang/crystal#16449)

It appears that doing this isn't really safe to do. Assuming that ENV["THING"] = ".." ends up going away, then it would be best to start thinking of an alternative here, and I had an idea.

The use of ENV["..."] in your app isn't great anyway.

1. You can't catch missing ENV vars at compile-time
2. They're always strings, so you end up having to do some casting when you need a non-string which leads to silly things like https://github.com/luckyframework/lucky_cli/blob/9598e572ac08483edb351eca74a8ecd24e472fb7/src/web_app_skeleton/tasks.cr.ecr#L8-L9
3. ... I'm sure there's more I'm not thinking of right now anyway.

LuckyEnv already comes with methods generated by macro that handle pulling the ENV value and casting it.

# PORT=8080
LuckyEnv.port #=> 8080

# ENABLE_DEBUG=true
LuckyEnv.enable_debug? #=> true

What if, instead of pushing everything in to ENV and using that, we went the other way and pull out what ENV has, and then push that into our own container and always call these values from LuckyEnv directly? You could still use ENV[] in your app, but that would just never include local .env file overrides and such.

For the time being, this will all just be discussion. I'll need to see how this goes with Crystal, and if it does end up merging in and no longer allowing ENV[] =, then we'll have to scope it to that specific Crystal version anyway.