Not just another .env parser

[jwoertink]

There's a lot of ENV parsers out there already, and the one we ship with has been pretty great. I think we can take it up a notch for Lucky integration though... I'm not sure how this would work, but it would be awesome if we had something that looked more like this:

# this is my .env
LUCKY_ENV=development
DEV_PORT(Int32)=3500
ENABLE_CACHE(Bool)=true

Then, we had something on the Lucky side that looked like

require "lucky_env"

LuckyEnv.development? #=> true
LuckyEnv.lucky_env #=> "development"
LuckyEnv.dev_port #=> 3500
LuckyEnv.enable_cache #=> true

By rolling our own, that gives us full control to start adding additional features that other Env parsers may not want.

• We could have auto reflection on LUCKY_ENV instead of having that class in your app's config dir.
• A special syntax for declaring non-string types
• Automatic method generation so your app calls these methods instead of having ENV[""] laying around. This also plays in to type-safety because how many times have you (I mean "I") done if ENV["LUCY_ENV"]? == "development" or something where you misspelled the key, but called ? because it wasn't really required?

Also, I've found myself following the Lucky pattern we use here quite a bit in my apps. It would be great to know which keys are absolutely required to be loaded in, and if they're not, then we raise a compile-time error to say "You missed one".

Lastly... I'd like to start thinking about how we get encrypted secrets in to Lucky. This could potentially be that way. Imagine you have this..

# .env.production
LUCKY_ENV=production
AWS_SECRET_KEY=aeihfaowehfgawe

Then locally you run a handy new built-in Lucky Cli task lucky encrypt_env .env.production
This outputs a file

# env_production.enc
LUCKY_ENV=sfhaoweiubvsadf
AWS_SECRET_KEY=9832y4r29fwe8hw38ehw

Then you cann LuckyEnv.lucky_env #=> "production" or LuckyEnv.aws_secret_key #=> "you get it".

Final thoughts

With that said, I could see how parts of this could be done using method_missing, and other macro stuff, but there's some talk floating around about method_missing maybe not the best thing to use. Also I'm not sure how we load this in at the macro level... Lots to think about